Handling internal IT issues

Question

In the company I work at, developers also serve as internal tech support. This means we have to do three types of things:

• Development: writing actual code to implement new features and new products
• Maintenance: handle bugs and minor changes with existing customer-facing software
• Tech support: handle internal issues other employees have e.g. locked out of AD, network drive is missing, internet is down, new software installation, need permissions changes, etc.

The tech support aspect of my job is the most troubling right now. This is because:

• someone with a problem will likely interrupt you immediately, taking you away from development
• problems come in too many ways: email, google chat, phone call, post-it notes on your desk, etc.
• people often cannot or do not determine the severity or scope of their problem before asking for help, i.e. simple problems that inconvenience one person might come in the same way -- and often with the same urgency -- as major customer-facing issues that could affect thousands

My question is: What are the proven methods for dealing with internal IT issues?

Should we use software designed for this purpose? If so, how should it be separated from any software used for customer-facing issues or bug tracking software? How can the IT/development department ensure it's used properly?

Also, is it a problem that developers handle these internal problems in the first place? Would it be ideal to have a separate person or department to handle these types of problems?

Answer 1

If your development people are fielding IT questions, and it's taking a reasonable amount of time away from development it's hurting your companies bottom line, period. It should be an easy sell to hire a part-time or full-time IT/admin:

• Figure out how much time each developer is spending on IT
  • This is the base IT personel cost of the company
  • This also tells you how much time/productivity is lost towards developing profit producing widgets.
• Take this to management, it should be easy to convince them a dedicated IT guy may increase profit due to reduced developer downtime (better bug fix and feature release turnaround)

As for the software aspect, set up guidelines for initiating an IT request:

• Submit queries via a ticketing system (most CRM systems have this, and there are quite a few free solutions)
  • CRM Solution
  • Zendesk (or some equivalent)
  • Trello

OR

• Submit via email (a gtalk request shouldn't cut it, there has to be some sort of trackability)
  • If this is the method, an internal address (ie. it@example.com) should be made to field these, and the appropriate emails added to this distro group, that way each IT person/dev doesn't get specific questions, but can be handled by whomever has some free-time.

If they initiate the convo via messaging (or anything outside your "tracking" system), have them submit a formal request through whatever system is devised.

The most important part of this is that you/your IT people (once hired) need to stick to their method and not let it slip, it'll streamline the entire process in the long run and not let things slip through the cracks.

Answer 2

Should we use software designed for this purpose? If so, how should it be separated from any software used for customer-facing issues or bug tracking software?

I don't see why not and I don't think it should be separate. It's more complicated to track different systems. Personally, I like systems that integrate with email. This way I can control all my "pop ups" and not have to manage too many apps at the same time. If the email contains a link to get right where I need to be for a specific matter, the better.

How can the IT/development department ensure it's used properly?

Like anything else, you have to define what "proper" means. Then it comes down to training, administration, and accountability. You're probably going to need buy-in from high up in the company if you want to be able to enforce its usage. There are a lot of bad habits you need to break here.

Also, is it a problem that developers handle these internal problems in the first place? Would it be ideal to have a separate person or department to handle these types of problems?

I don't know what is ideal. From a programmer's perspective, most do not want to deal with customers. The main reason is being interrupted. You can get around this if all the devs are "on call" for different periods of the day. If I know I have an uninterrupted block of a few hours, I'll make sure I spend that time on a programming project problem that I can fit in if possible.

There are some companies that make customer service so important, they make everyone do it for at least a period of time as part of their training. It can give insight on how the app is used. Releasing a known bug may get a second thought if you don't want those phone calls.

Someone running the company has to decide what is important and where do they want to make the trade-offs. Developers are expensive and they lose money every time a dev is interrupted. Support staff tend to make less money also. Not everyone is good at customer support or programming, so there are even fewer who are good at both. Depending on the current status of my team or the need to hire more programmers or replacements, I may think twice about this additional burden. If two jobs are equal in all ways except one requires doing tech support, it could be difficult to find good programmers because they'll take the other option. A company has to be really good in other ways to attract talent when the required duties are less than desirable to some.

Answer 3

I will presume your workplace is like 99.99% others and management will not give a head count increase in a whim. You also do not state you are over worked, so my guess is your ideal of a new department is not going to happen any time soon. Just asking for it will get you no where, you will need to show its needed, based on evidence. Without a formal system this evidence will not be available.

The problem is best solved by creating an SLA (Service level Agreement) for tech support calls. Some issues (network down) are more important that others ( Need to install Candy Crush on receptionists computer ).

Reach an agreement with management and users of how quickly you will respond to different request types. After this, reach agreement on how you will be informed of issues - an email to "support@acme.com" is the only software you need. High priority meeting P1's (instant response) is through phone call. Email is checked every couple of hours. Dedicated help desk software can come later, if at all.

Assign one developer to be on it support each week on a rotation. That week support is their priority job, and they are assigned non urgent development work. Other developers are not to provide support (except maybe priority calls covered under the SLA)

The advantage os this system is when you get the dedicated IT guy(s) the same system is used, and it can accurately track how much support is being done - justifying you request for a dedicated team (or not) as the case may be.