Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Should a software engineer also act as technical support? That is, should a company allow their engineers to wear both the software engineer and technical support hats. It seems that it would remove the ability to write software if much of an engineer's time is taken up by technical support.

share|improve this question
1  
By tech support, do you mean supporting the specific apps they're developing, or general "system admin" kind of stuff? I can tell you it's annoying working in a little firm and having people bug you to install Excel. –  Carlos Jan 12 '11 at 14:36
7  
Should we? No. Do we? Yes. I hate it. –  Rachel Jan 12 '11 at 20:37
3  
An engineer should always strive to make seemingly innocent mistakes that cause more work for the person who thought it would be a great idea to use them for tech support. –  Erik Reppen Jun 15 '13 at 6:15

17 Answers 17

up vote 61 down vote accepted

This is a classic issue in companies that have a software development component in their work, whether they are software companies or not. I struggle with this all the time.

Having Developers involved in Production Support

Pros

  • Fights "Development in a vacuum" syndrome. It's valuable to gain exposure to how users use the app. Until I finally saw this as a young developer, I didn't realize what a crappy UI developer I was. All I cared about was coding and not design, analysis or the user's perspective.
  • Developers that are not as good as they think they are can be humbled (although there's no guarantee you'll get this benefit; some devs are truly oblivious, selfish, and stubborn).
  • Developers will gain domain knowledge. This is critical if your developers are to eventually become better at identifying and filling in the gaps the business analysis phase (assuming there is any) misses.
  • Good support is a marketing point. If you do it well, clients will come to appreciate it. And a well-rounded developer with communication skills and domain knowledge is capable of doing this well. However, I would still prefer that applications be of high enough quality that they don't need support. Superior quality is its own form of customer support (and also a marketing point).

Cons

  • Interruption factor. This is the number one fault of mixing project work and support work, bar none. Projects interfere with support, and support interferes with projects. Projects depend on estimates and milestone progress, support is unpredictable and can involve impromptu urgency. Projects are schedule-based, support is interruption-based. Not a happy combination, and very frustrating for developers to deal with.
  • Not everyone is good at support. Someone that's less experienced with the app or business, or someone whose personality or communication skills are such that they are better shielded from user access might not work well in support.
  • Inefficient use of resources. Frank Shearar noted in the comments that a developer doing trivial support can be more expensive than a level one support tech.

In my experience, most developers don't like support. Having served on both the project and support sides, I can sympathize. When having to do both at the same time, the mitigating factor is often overtime, usually unpaid, to deal with support emergencies and still make project deadlines. Project managers love unpaid overtime because it means making dates without costing more money, but for the devs, it's just a big bowl of suck.

However, I also believe that if developers did a better job creating reliable and intuitive systems, you'd have less support. So this creates a weird circular argument for mixing the two. What I think you should do if you have to do both is find ways to avoid making it simultaneous. You may find this StackOverflow post of value.

share|improve this answer
1  
I think making support for a project in development isn't bad. Talking with client is good. But if you work on 7 projects with 7 different deadlines and urgency... After a while it's seriously not really good. it kind of suck very badly. –  Loïc Faure-Lacroix Jan 12 '11 at 1:29
3  
I have also seen shops where developers who miss their deadlines just shrug and say "I had a lot of support time this week. No bugs, the users just needed hand holding." Typically there was no way to tell whether that was happening or the developer was just slow that week. As long as you control for that, I'm in favour of developers supporting their code, but not as front-line phone answering support. –  Kate Gregory Jan 12 '11 at 1:43
9  
There should be a front-line support layer to catch the RTFM questions, leaving only the questions with useful technical content/feedback for the developers to field. –  Robert Harvey Jan 12 '11 at 4:05
3  
@Christopher: Self-describing systems are a nice ideal to strive for, but difficult to achieve in practice. There are many people factors and stakeholder pressures that conspire against doing them well, and there will always be users that "don't get it." –  Robert Harvey Jan 14 '11 at 0:18

I think that developers already wear two hats. Support is more like a filter used to shield development from trivial issues such not having the computer plugged in. However, there should be tight coupling between development and support. Some customers have legitimate issues that maybe the result of a bug. It should be the responsibility of development to help get these issues sorted out as soon as possible. So in a sense developers are already part of the support team...call it tier 2 support.

share|improve this answer

Emphatically, no.
We all know how difficult it can be to have to stop what you are doing to ask answer a question. I do answer phones for a help desk and I write some utility applications.

I cannot focus on solving a problem because every 5 minutes I'm having to pick up the phone. Neither job gets done as well as it can be because I constantly am thinking about what I can do to solve a problem, and I'm never working on the programming long enough to fully implement any solution I might have.

Again, I could not stress enough how important it is to be able to focus on one aspect or the other.

share|improve this answer
1  
You can set aside 'office hours' to avoid the interruptions. On call support is not a good idea. –  JeffO Jan 12 '11 at 0:43
2  
Agreed, also, semi-dysfunctional programmers don't make very good support people :) –  konrad Jan 12 '11 at 1:30
6  
This a poor answer in my opinion. A Dev who NEVER does support can never learn how their decisions affect the user, good or bad. Just watching someone try to use the software can be a major wake up call, even if you think it's matching the specs. There are ways to mitigate the negative parts of it, rotating schedules amoung devs, help desk to handle the weedout calls so you are only supporting your app, etc. If you have a dev that 'is dysfunctional', have to wonder how useful they really are if they can't even talk to the user. Supervise if necessary, so they can learn. –  Jay Jan 12 '11 at 20:39

I would never put a developer as first line support. The number of interruptions and the amount you will have to repeat yourself will drive most developers to shout RTFM and hang up on the next person who calls. This is not something your clients need, nor is this something you want your developers to have to endure.

There is a certain rule in any customer service position. To an irate caller, the first person who answers the phone is wrong. Whether they have the president of the company, the person who developed the app, or the support manager, it doesn't matter. Once the client gets the second person, who may or may not know what they are doing, the client will be able to calm down and explain the problem more clearly.

This is not an environment you want to retain good developers. Is there value in having a developer interact with a client on a particularly difficult problem that goes beyond "why doesn't my cup holder work anymore"? Absolutely. But that's after the support request has been vetted through the first and second tier support lines.

share|improve this answer

It depends on the company.

My job is exactly like this. I'm a software developer, but since we're a fairly small company, each developer takes on an "unofficial" support role usually based around their own software. Some developers have to do more support than others, depending on a number of factors such as how many products they have developed/shipped, how buggy their products are, and how effective they are at support. If you can provide the customer with exactly what they need to solve the problem, they will keep coming back to you to get issues resolved as quickly as possible. Double edged sword? Yes. You suffer from reduced productivity, but the customer is happy, and more likely to remain a customer. This is important for smaller companies.

We do have a systems support team, but because of the nature of what we do, they mostly have to deal with hardware related issues. Personally, in a smaller company, this issue isn't as disruptive as one might imagine. Sure, you get calls while you're trying to work out some important feature, but at the same time, the customer service is much improved; they can have an authoritative voice that knows (in many cases) how to solve their problem instead of someone with second-hand information and a support script. If you can't solve the problem there and then, can reassure them personally that you will implement a fix for their bug, or consider their feature request for a future release. You can get real feedback straight from the users of your software, so your next version can be even better than you already think it is.

I like to think that happy customers create a more positive image of your company, which usually leads to more customers. And that's why, as a software engineer, I like tech support.

share|improve this answer

Developers should be the last line of support.

Only when the helpdesk and our QA department cannot help a customer will we be hassled. And even then it has to go through our prioritized bug tracking system.

If it's a really big problem we'll hear it.

share|improve this answer

There is nothing more frustrating than computer tech support not willing to hook you up with someone who really understands what's going on. I would hope that any large application company would have some programmers who would work tech support.

share|improve this answer
2  
There's a certain law with tech support: the first guy you get is always wrong. He can be the most technical astute person on the team, and by virtue of the fact he picked up the phone first the client will not be able to trust them. Basically, the first guy exists to let the client vent and fume so that the next one can be the "savior". This is the case in any customer service profession--not just technical support. –  Berin Loritsch Jan 12 '11 at 0:26

I think a lot of it depends on the company. Your typical BigCo firm can usually afford to have support people to insulate the developers. On the other hand, a startup with three people total simply may not have the resources to provide separate support people.

I think the best general strategy (without regards to company size or resorces) is to use support teams to troubleshoot the low hanging fruit and the most common problems ("Have you tried turning it off and on?"). The engineers should work with the customers on the more tricky problems that require knowledge of how the system works along with more developer-oriented support (APIs, developer tools, etc.). You could have the support person act as a "liason", but I find that's usually more trouble than it's worth.

share|improve this answer

I would only do this if it is a new developer or one who isn't familiar with the domain and customer base. Making it a permanent thing is not a good idea.

share|improve this answer

My last job was exactly this. We supported existing systems and also wrote new ones as needed. It was a total disaster. I would constantly be interrupted. My morale was so low because projects started would take forever to finish. Also, we had to carry around a pager for off hours support without extra pay (this was in the health care field). I think the solution (which I suggested to my manager at the time), would have been to have a front line of technical support, and if it's a software bug then forward it along to the developers. Needless to say I only lasted a year and a half until I finally left for a better all development job!

share|improve this answer

There are talents and skills you need to develop software, and talents and skills you need to be effective on first-line support. I don't know that these talents have any correlation.

This means that either you have to hire developers based partly on their ability to do phone support, or you let your customers directly talk to people who aren't good at handling customers and don't want to be doing it in the first place. This may or may not be better than having them talk to a guy with a thick Indian accent who reads from a polite script.

Also, when you make the job unpleasant (and I don't know any developers who actually enjoy first-line support), some of your developers will leave. These are generally the ones who can get other jobs more easily: i.e., the good ones. As this process goes on, you wind up with a shop filled with less talented people, making it even less pleasant for the competent to stay past the first job offer from somebody else.

As far as getting serious development done, forget it if there's frequent interruptions. My wife has complained a lot about being expected to do development and support users simultaneously.

share|improve this answer

While I don't think it's appropriate to use devs as support all the time, I think there is something to be said for having a dev do the initial support of an application. This should specifically include the after hours support. I also think in can be useful to have them be scheduled in to the after hours support for their apps on a regular basis.

There is nothing like multiple 3AM calls to make you realize what effect certain design decisions and/or shortcuts have on the ability for people to support and maintain your code.

share|improve this answer
2  
Correction: There is nothing like multiple 3AM calls to make you realize what effect certain design decisions and/or shortcuts your manager forced on you have on the ability for people to support and maintain your code. Bad design and code is more often a result of bad management than bad programmers. –  David Thornley Mar 7 '11 at 16:13

Ideally no for the reasons sited above, but yes while the project is nascent, because developers can provide quick resolutions, often expected by business, which lends support to the continuing improvement of the software. I value developers that provide support smartly: those that lend their analytical skills by example to a more formal full-time support team, and those that answer the business in such a way to show a spirit of service and cooperation. Keys to this success though include management recognizing and formalizing first and second level support to quickly offload developers from what should only be their short-term role. Developers who show a knack for both development and support should be cultivated as third-level support, or support for the support folks. So should is time dependent, talent and desire dependent, and effectively managed.

My own interest has been to answer the tough support questions, and to take what I've learned from the experience to reduce the need for support overall, which benefits end-users and primary support alike.

share|improve this answer

Some of the time, definitely yes. Facing the customer often gives a perspective that most people, especially programmers, lack. How the user actually uses the product, or actually thinks is often far removed from how the builder (the engineer) thinks s/he does.

It should be for short periodic stints, so as not to interrupt the actual task of development.

share|improve this answer

Cons - assuming you have to deal directly with customers.

1) Spoiling Your Customers

If it is first/2nd/3rd line support (i really mean blurred line support) where developers deal directly with customers, then it is a big con. Developers have the skill set required to debug problems or develop solutions to solve problems. If customers have complete access to developers (blurred line) - there's no stopping customers from "abusing" this privilege - resulting in spoiled, demanding and privileged customers that are paying no more than any other customer.

2) Conditioning Your Developers to Lie and Make Up Stories.

Anyone who has dealt with customers know that it is a pre-requisite to be able to lie to them. There is a bug with a 1 line fix that can be done in 5 minutes. A customer support person would have been trained to manage customer's expectations - that it would take up to 3 days to get it resolved.

As a developer, if you have to deal directly with customers, you have to think of creative ways to appease or deceive customers when your primary job should be to solve technical problems and make sure the system is running smoothly.

3) Your Curriculum Vitae Suffers.

Unless you're making a switch from Software Engineer to Business Analyst / IT Consultant / Project Management, your CV is going to suffer from a technical aspect.

Paid support work that rotates among the team is a different story.

Pros

1) Stop Whiners from Whining

Developers who do what they hate will make them appreciate coding a whole lot more. Have a programmer who is constantly whinging? Put them on the hotline for a month.

share|improve this answer
3  
Put them on the hotline for a month. Then look for a replacement developer, because that guy's not going to be around long. Further, look for somebody good at customer relations to soothe the ones who talked to a person who was in a bad mood before he or she was assigned to do something he or she hates and which shows no respect from the company. –  David Thornley Mar 7 '11 at 16:02

I got into this trap when I joined a company with good pay. During the interview I have been told that there will be 70% development and 30% support and I accepted the offer. May be it is the company or environment that I'm currently working on. But actually it 90% support and 10% development. Its been a couple of years now I lost the grip of development. I regret that I accepted this offer.

But I feel like I have lost the grip of coding more over there a lot of new technologies and frameworks. Now I don't know where to start again. I keep on preparing but these helloworld examples are not enough to have some good practical experience and it is really getting difficult to update my knowledge and experience. I can't even leave my job to start over because of family commitments.

Unfortunately I'm in a deadlock.

Please don't accept roles if you dont like or not interested in.

share|improve this answer

Yes of cause they do. I lol'd when I read this question? I was like how is this even a question (not that I'm questioning your right to ask the question OP), but its quite rhetorical because almost every Dev I've ever met has had some type of technical support work implicit within his or her job function. You simply can't avoid it. In most cases your the most technically compitant person not just in your functional domain, but in terms of IT in general. It's very hard to avoid completely.

share|improve this answer

protected by gnat Apr 15 at 9:05

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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