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.
related: programmers.stackexchange.com/questions/8301/…– spongJan 12, 2011 at 7:41
3By 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.– CarlosJan 12, 2011 at 14:36
13Should we? No. Do we? Yes. I hate it.– RachelJan 12, 2011 at 20:37
7An 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 ReppenJun 15, 2013 at 6:15
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
- 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).
- 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.
1I 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. Jan 12, 2011 at 1:29
4I 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. Jan 12, 2011 at 1:43
15There 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. Jan 12, 2011 at 4:05
5@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." Jan 14, 2011 at 0:18
1An excellent answer. My company finds a nice middle ground - each dev spends one day on 3rd line tech support, rotating through the team. If you're on tech you can be interrupted within reason, but everyone else is immune unless something major crops up. During our days on tech, we tend to do lighter bug fix, admin stuff etc to avoid being in something complex when interrupted... So basically we all get a day to do the crap developers hate doing but have to do, but know that we get occasional support calls to break it up. More importantly, it's great knowing you're immune the rest of the time! Oct 24, 2014 at 1:19
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.
+1 I can relate to everything you said. I was in a similar position a few weeks ago. Now we don't have phone but they knock the door anyway, even for stuff like:"hey guys, have you seen X around?" geez!– jasoncoJan 12, 2011 at 0:40
1You can set aside 'office hours' to avoid the interruptions. On call support is not a good idea.– JeffOJan 12, 2011 at 0:43
2Agreed, also, semi-dysfunctional programmers don't make very good support people :)– HomdeJan 12, 2011 at 1:30
9This 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.– JayJan 12, 2011 at 20:39
1@BryanOakley: have a plan that will get tech support. While I still support my answer, it is unrealistic to expect a start up to have all personnel necessary for adequate customer support and development. I would still recommend that a developer's primary task is development - not customer support. The problem is that when a developer has close ties to a customer, the developer will either: (a) always be contacted directly by the customer instead of proper tech channels, or (b) end up developing specifically for that customer's needs rather than the broad scope of necessary development. Jul 12, 2013 at 18:28
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.
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.
Zappos has built an empire that goes against the first person rule.– JeffOJan 12, 2011 at 0:46
I don't know about Zappos, but it seems true enough for most companies. All I know is that if I'm frustrated enough to call tech support, I feel bad for the person on the other end of the line. Jan 12, 2011 at 1:07
Never? As in never, ever? Even if you were a small company made up of salespeople and one or two developers? Not even if your developers were very strong communicators and liked talking with customers? Jul 12, 2013 at 18:27
You want your developers to be perceived as knowledgeable--make them the second person the customer talks to. By then the customer will calm down some and behave a bit more reasonably. Now, if it's a customer you have a good relationship with and it's not the first introduction the developer has to the client, then it would be perfectly fine. First contact should be vetted through someone else first though. Jul 13, 2013 at 18:03
As somebody who has been first-line support - I think the rule for the "irate caller thinking the first person who answers the phone is wrong" is not correct. Though, I can only speak from my own experience. The occasional irate caller who does think this either realizes their mistake (as long as front-line actually is knowledgeable) or they are simply not looking for a solution, but rather someone to blame - which means nobody can help them. I do still agree overall - developers should be the last contact, once it is determined there is a bug somewhere(or high possibility of one) Oct 23, 2014 at 18:08
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.
I'm in the same boat as you and fully agree with you. However, it should be possible and more often that a receptionist takes the call and writes down a note for you to give that customer a call back. That way you can go on not getting interrupted in your work and call back when it suits you best. Do however call back the same day, preferably within 2 hours after the call came in.– HtbaaMar 23, 2011 at 8:07
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.
4There'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. Jan 12, 2011 at 0:26
@BerinLoritsch That is a law that is learned from experience, not an unjustified prejudice as you seem to imply. I don't know what it would take to convince the support center that, yes, I have tried the usual solutions. Obviously it can't be based on what I ask for, but I have noticed that in 20 words or less I can know if the person has done his/her basic troubleshooting.– Milind RNov 10, 2014 at 8:09
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.
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.
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!
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.
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.
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.
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.
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.
5Put 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. Mar 7, 2011 at 16:02
1Agree with David, if you have to run your team like a classroom, you may want to reconsider your hiring practices, and/or your work environment.– MatthieuDec 9, 2011 at 6:03
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.
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.
2Correction: 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. Mar 7, 2011 at 16:13
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.
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 (irrespective of company size or resources) 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 "liaison", but I find that's usually more trouble than it's worth.