IT Job Advice: Tickets/Work Orders

 I'm going to be honest here, I hate ticket systems. I hate filling out tickets. One thing I was never taught in school when learning IT was that most of the job is actually a bunch of bureaucratic fluff. I mentioned in a previous post that documentation is super important and an easy way to get you some praise at your job. Another piece that requires little technical information but extra stupid paperwork is tickets.

Here's the thing with tickets, I've heard the arguments about tracking work done for historical purposes, using notes for fixing future things, etc. Truth is, I've never seen it used for that at all. Notes are often useless, and often times important historical detail is left off or there's lies in the notes. The truth is they provide on important thing that allows IT managers to negotiate with HR, payroll, and hiring managers, and that is METRICS! That's right, it's all about tracking work hours. So why are the notes needed? To justify the hours the ticket represents.

So how does one be successful with tickets? The first is, add any notes you can, it doesn't even have to be fully technical. You just need to show "I did X task(s) and it took ## hours" in such a way that the hours spent are justified by the task performed. Also, attach any and all communications around the ticket to the ticket. This will also be a good cover for if a task takes too long or if a user lies about something communication-wise.

Another important piece that relates to the metrics ticketing systems offer, is meeting a Service Level Agreement (SLA). Keeping the metrics looking good, or having a documented justification when something is going a bit sideways will get you praise from managers up the chain with everyone concerned about what those metrics mean.

So the simple flow is as follows:

• Tickets track hours
• Notes justify the time spent
• Communication justifies solutions or breaches an SLA

The metrics there can then be used to:

• Justify the job or needs for more people or time
• Justify why an SLA might have been breaches
• Prove the situation was resolved or whatever closeout reason was used

Despite all of these good reasons, tickets still suck. It's time consuming and feels like a waste of time when you could be doing something productive. However, if you want to succeed in IT, fill out tickets as best you can to meet these specific notes and you should be successful at your job.

IT Job Advice: Documentation

Back when I started in IT, specifically back in college, there was a lot of advice I never got. When I got my first real IT job,I'm I thought the most important thing was technical skills. Now, I've learned something very important I wish I knew when I started. There's is a way to make a huge impression very quickly, faster than you can with demonstrating actual technical skills, even with limited technical skills, and secure your way to actually getting promoted. The biggest skill you can have is documentation. 

When I started in IT, I never thought about documenting because a lot of it seemed super simple. After years of pricing what I could do, I got asked about documentation. When I wrote it, I got told it was the first thing they ever read. I didn't understand what they wanted then, but now I know what was wanted. It may sound stupid and annoying, but what a lot of bosses in IT seem to want is easy to follow documentation so that anyone on your team can do the exact same things everyone else can in a pinch. 

This leads to a few different types of documentation you can make. The first is instructions. Given a scenario, follow the steps and even a trained monkey can look like a tech wizard. Another type of documentation is the broader troubleshooting guides. Give some commands or things to test and some dynamic workflow to either get a solution or information for a solution. Then we have diagrams. Explain what is plugged in where, how, why, etc. so that people can find what they need even if they don't really know what the setup should be. We also have the contact list. Who to contact for what with all the information needed. 

By creating documents like this in any format your job might have available, you can get instant praise at any IT job. A common problem occurs, link a document so no one needs to even ask about it repeatedly. Internet goes down, have the number and information on have ready to go with emergency level speed. Need to find where a specific device is plugged into or where a cable goes, check the diagram. Don't know how to troubleshoot some proprietary software your company uses, have a guide ready for your specific use case. 

I never really documented until my current job. Now, I work on a OneNote and SharePoint with a coworker. When a new lead took over, simply linking the document got us praise before we even demonstrated a single technical skill. It's even gone a step further into us attempting to document all the historical changes so we can go back and reference anything that anyone else has done. 

Now let's talk about verbosity and technical level. For emergency info like contacts, cut and dry works. For everything else, assume whoever looks at it, it's their first day on the job. Be specific, hand hold, and if needed, reference other references to detail acronyms, systems, and software. We're taking RFC level verbosity with day 1 technical hand holding. 

This is the advice I wish I had from day 1. Now let's say your job already has documentation, then what? Update everything you come across, full in any missing detail, and always tell people you updated or fixed it. You will get on much easier in your IT career if you document, talk about documenting, constantly respond with new updated documents, and make a workflow all about documenting.

Hope that helps anyone getting stuck in their IT career!