How much client support is reasonable for a developer?I work for a small software firm, and I am one of two developers on staff. My coworker and I handle more than half of the support calls. Support calls are a given, there is no stopping them especially since one of the selling points of our flagship product is "free non-outsourced toll-free phone support". Usually, this gives us only a week of steady development time during the month, and sometimes the phones are so busy it leaves us with doing band-aid fixes to keep customers from calling just so we can get a little bit of the more urgent work done (more urgent == boss wanted it yesterday).
This has become a vicious cycle - the less time we devs have to work on improving the product, the fewer problems we fix and the more calls we get. The more calls we get, the less time we have to work on the product. When I was hired, I was told I wouldn't be doing support, which lasted about four months before I was given support tasks to do. Our development responsibilities have increased dramatically since I was hired, we have double the client base but still the same number of people running the show. Coworker and I have brought this to my boss's attention multiple times, but nothing has changed around here. Some of the ideas we had that were turned down:
Don't get me wrong, I see the necessity of developers supporting clients directly when it comes to errors in the code or when the office is shorthanded, especially in a small office such as ours. But having the people responsible for the reliability and success of your flagship product stuck on the phone all day rather than keeping up with bug fixes and documentation just seems like a recipe for eventual disaster.
I'm curious as to how good companies (as in, companies that don't score a 1 on the Joel Test [1]) handle customer support with their developers?
Thank you in advance!
ACCEPTED]
A developer should not also be acting as front-line phone support!
(To clarify: staffing the phones for support is not the same as the regular contact that you have with the customer during an agile development process.)
In a good company, you would have a project analyst who speaks to the customers, answers their questions, understands their requirements, documents them as use cases or bug reports, and prioritises the work for you. They can also do things like demo new versions to customers and perform testing.
Doing all this for the steady stream of bug fixes and feature work should be a full-time job, even with just two developers. Expecting developers to be constantly switching roles is wrong, no matter how big the team. One project analyst and one developer would be more efficient than two developers trying to handle both roles.
I can understand why your boss might not want to hire more people, however if he or she believes that the most efficient way to run things is for the developers to fulfil two jobs at the same time, he or she is clueless. Having poorly defined roles within a company is sapping to morale and poisonous to efficiency.
A commenter said:
A good manager would be tracking these defects and starting to focus entirely on taking away the reason for the calls to begin with. The main reason for the dev to take the calls is to understand why their product doesn't solve the customer issues OR causes problems.
I thought this was an interesting insight into why somebody might think that making developers take support calls from customers is a good idea, but it's based on an entirely imaginary premise, i.e. that the calls will ever go away.
When you develop software you have to accept that there is no such thing as perfect software. And even if you have an incredibly low rate of bug reports, that still doesn't account for all the calls which are caused by missing documentation, misunderstandings, new feature requests and scope creep (which I often see as "feature requests masquerading as bug reports").
In fact, as the company becomes more successful, the amount of interaction between the company and its customers is only going to increase! So, expecting developers to shoulder all of this responsibility as an incentive to improve their work is illogical.
Of course, the developers should absolutely understand what causes issues for the users of their software, but this can be communicated to them at regular scheduled project meetings, not by a ringing phone which interrupts their work.
It sounds like your business has grown sufficiently that you should hire someone to focus specifically on support (taking calls, and performing the bandaid fixes), so that the developers have more time available to work on new features, as well as more serious fixes to the support issues. As it is, you're losing too much time in context-switching to be able to get much done.
However, you've already proposed many great ideas, so if they aren't being taken seriously, you might have to consider throwing down the gauntlet and being serious with an ultimatum. Sometimes it takes a good developer leaving for management to understand the seriousness of the situation.
I have not done much end user support in my programming career and I don't work in a firm so I don't have that much experience in the field, but what I would ask for (or if it doesn't seem wise to right-out ask, try to find out) during an interview:
How many people are handling end-user support full time? If the answer is "none", are they at least aware that this is a problem? Is hiring such a person at least planned?
How is end-user support handled in an everyday scenario? Is there a non-programming person handling and filtering the calls? (Support calls going directly to developers' desks would be a reason to run away for me.)
What structures are in place to inform developers about bugs reported by end-users? (If the answer is, "why, we just walk over to their desk and tell them", run.)
How are bugs managed? (From the Joel test, really.)
And last not least, make sure you cost your employer enough. The more expensive you are, the less incentive is there to have you do unfiltered end-user support without getting around to any actual development work.
Also, it's probably good to try and pick up the general vibe present in the company. Everyone talks about being totally devoted to customer service and whatnot. It's in the nuances whether this means the kind of unbearable situation you describe, or whether there are people at the helm who understand that developers need the space and time to work in peace much of the time to do good work.
And your ideas are brilliant, btw. I don't understand how any sane employer can refuse them.
I'd say that any "good" company would analyze the cost and benefit of having developers on the phone with the customer. In most larger companies, this is a no-brainer and the developers never hear a phone ring. In the case of a small business, it is much harder to make this argument. I dealt with a very similar situation a few years ago, and was able to make improvements through subversion (no, not SVN, subversive behavior). You will need your partner's help, but I'm guessing that wont be a problem. Here is what worked for me:
If step 4 still does not produce action, I have a few links for you:
Good luck, it is a tough battle with people who can't comprehend that your job is anything different from typing an email.
[1] http://www.fogcreek.com/FogBugz/StudentAndStartup.htmlYou should always have some form of first tier support to (a) handle the "I forgot my password"/"where's the any key" type calls and (b) enter all contacts into some sort of database that is then prioritized by some sort of manager. Customers should not be calling developers directly for not only the (very valid) reasons you listed, but also because you as a developer don't know what other types of calls are coming in and whether or not your call is the most important iron in the fire[1].
Helpdesk calls should only be escalated to developers if it is something the first tier (which should be trained in installation/configuration/etc) can't figure out.
[1]Let me guess -- "they're all important" is the answer you would get...
You should definitely be thinking in terms of hiring somebody dedicated to support (at least a part-time person, but preferably full-time). A developer doing support once in a while is definitely a good thing -- it helps maintain their contact with (the customer's) reality. At the same time, most developers have entirely the wrong mindset to do support very well -- they think far too much in terms of changing the code, and far too little in terms of how to use the code as it stands.
Though it's not all that big of a factor in reality, an argument that tends to work well with most boss types is that dedicated support people generally cost quite a bit less than developers. More importantly, they tend to do the job better -- communication skills that qualify as good to excellent for a developer will barely qualify as mediocre for a support person.
Well, it's obvious what a good company would be doing, and it's obvious that your company isn't doing it. You have good ideas, and the company isn't implementing them.
There are two things that strike me.
First, they changed the job description on you. I don't know if there was any warning, or if things just came up, but there's at least the possibility of dishonesty.
Second, they don't respect you. You see a real problem, and have been suggesting ways to improve the situation, and being shot down.
This is not a good situation to be in. I don't know how you're supposed to figure out whether you're being lied to in the interview (and it has happened to me). If you can talk to somebody who's doing what you'll be doing in the process, that's great, and it doesn't happen all that much in my experience.
My advice is to get out as soon as possible. If you've got stock options, forget about them. The way the company is being run, they are unlikely to be worth anything. Find another job.
I worked in my first dev job for 2 years until I ended up in exactly (word for word!) your situation.
It came to a head when all dev was done as (unpaid) overtime because so much time was lost answering phones and talking/arguing with customers.
I was quickly becoming totally jaded to the job and my boss picked up on the drop in productivity. We tried to implement a proper work request system (where customers would email or phone in their problems, we escalated them to our boss, who would tell the customer the price and time frame) however it quickly fell apart. Established customers were not happy with the change in pattern from "they ask, i do" to "fill out a change request, we'll invoice you" and to keep new customers interested the boss would pull rank "big client, drop everything (again...)".
It got a bit uncomfortable, I quit, took another dev with me. Got a new job being paid much more working 9to5 on interesting projects with about 1% client contact.
I'm all for devs talking to clients when it is appropriate ( no point non-techs trying to shout error codes accross the office) but they should not be first line support.
Make some unhappy noise, if your bosses wont take you suggestion on board you might have to make some more aggressive noise like "I'm not sure I can continue performing two roles on a long term basis" but make sure you're prepared to have your bluff called, hopefully it will never come to that (any boss who would rather let key staff walk than listen to them is an idiot) but keep half an eye on the jobs market just incase...
The problem is right there in your first sentence "I work for a small software company...". If the company is small, and yet you want to provide a high level of support, everyone ends up on the phone. You and your boss can spend all day discussing why developers should focus on development, but if the phone rings, you have to answer it. If you can hire someone new, great. If you can streamline your processes (bug tracking, etc) to free up time, great. But until you are able to grow. this situation probably won't change much.
This does not mean that you don't work for a 'good' company - just a small one.
If you have a way to identify and prioritize the reasons for the phone calls, and then use what little dev time you have to patch up the biggest problem areas first, you may be able to gradually reduce the load.
Can you tell us why they rejected those ideas (most of which sounded reasonable to me). Maybe you didn't do a good job of selling your ideas?
Find out what would make your boss sit up and take notice and provide him that info. Then sell him on the ideas you have. Get a management type person to help you with this if you can, not necessarily someone who works for your company but a friend who has the management perspective willl help.
I know that this sounds like I'm making it out that it's your fault the ideas weren't implemented but frankly that is something you can control and fix and the fact that your boss is an idiot can't be fixed at the organizational level. If you don't think trying a better sales job will work, I really see no better option than moving on. This place isn't helping your career and they won't show loyalty to you (Or even help you fix an obvious organizational problem), so why should you show loyalty to them?
Give your boss a link to this thread. You haven't said anything disrespectful, and he/she will see that this is not how the business should be run.
Been there, done that. Several times.
This is not a maintainable situation for the company. It will just continue to get worse unless someone does something about it. The users will get more and more annoyed -- and there will continue to be more and more users -- until they demand more and more quick fixes; the quick fixes will lead to bad design choices, through no fault of your own; the pressure will cause mistakes which will then cause more quick fixes which will cause more pressure.
I know you're a small company, but it sounds to me like you don't have any support methodology at all. Are you given a chance to distinguish between bugs and enhancement requests? Are bugs triaged, or do you have to fix all bugs, NOW?
And when I've been in these situations there is normally very little development methodology, too. Who's doing the testing? How are releases controlled? Do you have source control? Do enhancements go through an approval process?
You don't have to answer these questions here. But if you are getting a lot of 'no's, maybe it might be an idea just to look for another job!
If you're getting a fair amount of yes's then it might be worth trying to persuade your boss to take onboard some sort of simple buzzword methodology like, say, ITIL. He may see it as something to sell the product with. Be warned, these things tend to grow like topsy -- you will want the absolute bare minimum of structure. But if you can sell your boss on implementing just a little of it, it will help a lot.
I have been there. I was a developer for a large healthcare company. Surprisingly enough, they had the developers doing phone support for the hospital for anything in which we developed we continued to support. Needless to say it's hard to finish any new development when you're constantly being disrupted by telephone calls and emails from users. So what ended up happening was no new projects were being rolled out very quickly.
I left because most of my time was being used support.
Finally (only after I left and I re-iterated in my exit interview this very problem) - they realized they needed helpdesk people to filter out the calls.
I would suggest to the boss to hire a "cheaper" admin type person. Say that the pair of you are not getting enough code written because your time is being spent on admin things, like ordering office supplies, updating the company web site, and answering the phone for trivial questions like I Forgot My Password. Point out that an admin type, who could be trained in a day or so, would need far less per hour than you two skilled developers, and you could get more coding done, adding features so they can sell more copies.
At first, the admin's main job would be to answer the phone and pass the call to one of you. But over time, the admin could learn to handle up to half of these calls, leaving you uninterrupted. You may also be able to work out some simple rules (me in the morning, the other dev in the afternoon) directly with the admin (since they make perfect sense) to get you some flow time. What's more, the admin may be able to help with QA and requirements gathering to give you a major productivity boost.
What you do have to consider, though, is that the product is actually complete. In the boss' mind, it may need nothing more than support and bugfixes. And perhaps the boss is thinking "I am almost ready to retire and don't need to design/invent another big product." If that's the case, nothing you say will move resources from support to development. Start looking for a different job.
seems to me like the software will always be full of bugs and eventually no one will buy it. If your dev's can't find time to write and test code for answering the phone then the code will most likely product more bugs and create more phone calls! It's a snow ball getting larger and larger.
Bail out when you can and find a job working for someone with brains!
If you are in small company than developers have to talk to the clients directly. otherwise developers should not do the support.
Read the Getinng Real [1] book, and learn that you should build simple products that will require few support. Also choosing the customers is something your boss could do. The kind of customers I avoid :
Those kind of customer are very likely to ask for some changes, improvements,... and think you're the person responsible of all the problems.
Also you can limit the client support. 1 month after the shipping is quite reasonable, then for 3 month ask for a little fee, and then ask them to f****ing pay !
It's better to have few high quality and simple projects than a bunch of lame ones, this is why i'm leaving my job (i tried to explain it to my boss but he couldn't understand).
Like everybody seems to say you're working for a lame company, so you have three options :
There are a few different problems here to my mind. First, have you had a discussion with your boss over how much of your time should be spent on support? Have you logged what percent you are spending on those support calls rather than dev work? What structures do you have to prevent the cowboy development that can happen where someone is almost developing right in production that can be disastrous.
I'm not sure that looking at what a good company does would be helpful here. How many support staff members are there? Are the executives of the company aware of how much it may cost to have a developer doing support most of the time?
In a job interview, I'd be tempted to ask if developers handle support issues and what controls are in place to prevent developers from being flamed heavily by customers. For example, if a customer calls and it cussing and swearing throughout most of the call, shouldn't there be some recourse for the developer to not have to take the verbal assault that may be coming from a disgruntled customer?
The vote to close reason was listed as "Not a real question" which I can see in that this isn't a specific question but rather a general question of, "How do I get out of doing so much support it is stressing me out!?!" in a sense.
EDIT: If you are open to spending a few more months on this, I'd suggest tracking time in various buckets,e.g. support, development and administration, for a month and then talk to your boss about the distribution and see if this gets their attention. The second month is mostly one of discussing and possibly trying to fine tune with another month spent seeing if the results work out or not. I don't suppose either boss could see a reason for having a manager position created that handles the releases and overall development flow within the company, eh? That would be my suggestion as in a sense what is needed is someone to shield the developers to some extent and provide order so that the chaos that rules now isn't permenant. I'm sorry for not having a better answer for you.
Heather,
All your ideas were very good! If they were all refused....well...that's a shame for sure.
Here's one that you should add to the list - a raise! You're doing much more work! They have more customers now too, right?
Sadly, this can be the life of a corporate developer who has to answer to "the man". As it is, they're making out well since more income has cost them nothing more it seems.
However this is also a problem that will only get worse!
In my opinion it depends greatly on the size of the company . . . as a general rule, the smaller the company, the more hats everyone needs to wear. I'm a software developer at a company of 30-some people, and I don't have to talk to customers directly very often, but I do get their questions passed on to me by our client services staff and have to spend some time addressing these almost every day. (I like to think of our business staff as the CAL -- customer access layer.) I find this somewhat preferable to the clients having my direct number, since I don't have to drop everything and lose my train of thought the moment a call comes in.
It sounds like the real problem in your situation is not that you're sometimes having to wear the customer service hat but rather that your job responsibilities were mis-represented to you when you came on board, and your boss isn't being very receptive to feedback.
It is in my opinion that developers should be exposed to some client support requests. The trick is getting the balance right and getting developers exposed to the right kind of support requests. As already mentioned, the sort of support requests you don’t want your developers exposed to are the ‘1st tier’ support requests:
Hey I forgot my password, can you reset it for me?
The sorts of support requests you do want your developers exposed to are the sorts of things that will help them build a better product:
Hey, when I press the sign-in button, I get this strange 404 error.
The difficult part is working out if someone is calling up because they can’t sign-in due to them having the wrong password or if the application is malfunctioning.
The other problem, is how can we deliver the important content to developers without breaking their concentration every five minutes by a ringing phone?
Bug tracking is a great answer for half the story – delivering information to developers in ways that doesn’t break their concentration. However, it still means that you need someone answering the phones and separating the wheat from the chaff. Which, for small software firms, might be prohibitively expensive.
A cheaper option could be to use an application analytics product like UserMetrix [1] to instrument your application and seamlessly gather problems with product user-experience automatically, just by users interacting with your product.
[1] http://usermetrix.com/java-analytics99% of our support calls are "How do I do x?" and similar mundane stuff, and is already answered in the documentation. So 99% of the time our response to a caller is "That's answered in the documentation. We'll have someone look that up and email you the answer immediately". That has satisfied essentially 100% of callers.
The vast majority of questions are one of 30 most popular questions collected over the years that are grouped into a README! document displayed by our installer and easily displayed or printed at any time by customers. So, the email we immediately send out in response to a call is usually "See question x in the README! document, which can be displayed by...". The idea is not to give them a fish, but teach them how to fish (ie, RTFM), so they learn how to find the answer to their next question and avoid having to call us again.
All other questions/answers are retained in a boilerplate email archive, so we can still quickly find and email the previously written answer for the rarer questions that are called in. Any genuinely new question (which now happens very rarely) is added to the archive for future reuse after telling the caller "We'll have someone research that and email you the answer as soon as possible".
For users that want over-the-phone handholding as they install or operate the product, we've created a snapshot-by-snapshort tutorial shipped with the product to step them through all operations. If they aren't using the tutorial, we ask them to start it and call us back or email us when they get stuck.
I, for a change, think that a developer should be on the phone to the customers!
I think a good developer should have the following qualities :
A good support guy (or business analyst) should have the following qualities :
From this, it seems pretty obvious to let the developers handle the support requests. There are other ways to ensure a sufficient time in the zone for developers, such as rotating "phone support days" between developers.
