Should software engineers also act as tech support? [closed]

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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!

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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.