Looking for advice on job situation

coyoterey

I only just started in the world of IT. Started my first job at a private university in February as a service desk tech and was learning a lot the first couple months. In April I was pulled off the service desk to begin writing documentation for a new program the university is developing. This program is entirely web and Amazon cloud based. I still do the service desk for this program, but there's zero activity for it since there's no students so I'm not learning anything in that regard.

My entire day is spent staring at a Word document, trying to figure out how to write documentation from scratch that I have zero experience in and close to zero guidance as my manager doesn't really know what to do with the documentation either. I'm not really learning anything technical, as I'm writing documentation for education based programs (like Banner and articulation processes). Every day I think about starting the job hunt again, but I'm nervous since I'd only be here five months. They're telling me I'm going back to service desk once documentation is done, but this is slated to be completed mid December.

Unsure what I should do in this situation. Sorry if I miss some details, writing this on my phone.

scaredoftests

Have you talked with your manager about this? Start sending out resumes if you not happy about waiting until December to go back to the service desk and your talk with your manager goes nowhere. Nothing harmful about sending resumes out unless you tell your present job (which you SHOULD NOT).

DatabaseHead

I used to be impatient all the time, and decided to start sticking it out and good things started happening. I had to actually do accounting functions for a few months once. Kind of bizarre for an SQL guy, anyway my point is if you do this without complaining you will accrue equity with your boss. This could "potentially" lead to bigger and better things.

In other words you could try to leverage this situation. I would consider it, but I am probably in the minority.

Also this is another huge bullet point on your resume.

"Oversaw and developed software content library, including the creation of standard operating procedures and software user manuals".

See if you boss will get you a license to Visio and build out your workflows in your Word documents. You can embed those diagrams into your documentation. Another skill to get on your resume!

Just trying to find the positive here and it looks like there are plenty.

hisesa

Summertime in a University is when all the gruntwork projects happen. Take advantage of it and make yourself an expert on the stuff (Banner) you're doing documentaion on. When the students come back in the fall you'll be crazy busy on the Service Desk for a while!

ThePawofRizzo

You're not learning anything while doing documentation? Really? Even if these are processes you are familiar with, you are learning to actually do useful - hopefully - documentation. Users are not IT folks, as you know, and so use the time to research and create a "standard" template or two in Word to provide a consistent document style for readers. Learn how to create docs that users can get the most out of that are both efficient, clear, and useful. Develop a procedure for others to test your documentation to make sure your writing is clear and concise. Documentation in IT is an extremely important skill that few IT personnel possess nor do they do it. In learning to do documentation and do it well, you are adding something to your skill set that you can bring up in interviews later, and managers will take notice.

I understand documentation can be a big bore, and I try to balance how much I do along with my techie work, so I'm not trapped becoming only the department tech writer. However, in my last two jobs I landed them, in part, because I told them I could document processes, and had experience in such. (Note, if you don't truly have writing skills it will become very apparent very quickly.) My current bosses have told me they like that I bring this skill to the table, and have asked me more than once to create user "how to's" when we implement a new system. I'm a System Engineer, and even create the docs for our Service Desk for troubleshooting the systems as well as configuration documentation on systems I've built. My current boss has told me even in the last two weeks, "I like the unique skillset you bring to our IT department." when referring to the documentation, because that is something few in IT do at all, let alone do.

Years ago, at another employer where each engineer was responsible for providing a DR/continuity process document for the systems they supported, I provided my IT manager with probably a 150 page guide for a business continuity and DR recovery process. Two of the SAP engineers were also assigned the task of creating similar documentation around the SAP system. After a DR test we presented the documents to our manager. I set my small "book" on his desk and he flipped through the pages of instructions, complemented by screenshots, bullet lists, a contents list, etc. The SAP engineers handed their single page, hand-written doc to him "outlining" their DR process. My manager looked at it, and said to them, as he handed their "note" back to them, "I want your document to look like Rizzo's." That's all I needed to hear to know documentation skills are valuable.

You may not love documentation, but try to find the value in having strong skills. Such docs can make your future IT life easier by providing an interface for users or other IT personnel. You can actually save time with useful documents because the Service Desk can provide the info to users without asking you a thousand questions, and other techs can review them to see how you have set up a system. Notable documentation skills can provide doors to other companies as others who benefit and use your docs go to other organizations, and drop your name when a new position opens because they know you can make an IT department appear more helpful to the business with our docs. You don't have to love to write, AND you don't have to write all the time, but there can be great value add for potential employers.

coyoterey

My main issue with documentation is that I'm getting close to zero guidance because no one here actually knows how to do it either. They just gave me the task and check in every two weeks (with different and contradicting advice). On top of this, I have no real world IT experience. Working on documentation is not giving me that experience, because I'm documenting non-IT related processes.

This is not me whining about doing a task I don't like. It's being concerned about my resume when all I can bring to the table is experience documenting education related material. I won't know how to setup a server, or fix a students technical problem. But I'll be an expert at telling you how your transcripts work!

IS3

Documentation could be very different in every organization but the way i do documentation at my work is I use the Snipping tool to capture an image of what i was trying to document and then write a caption or the steps taken to accomplish the task. Same thing when i do software install or even "How To's" i would snip every single step with captions.

danny069

Writing policies and procedures are a good thing you can put on your resume. You can also highlight the security aspects as well. I would also take advantage of tuition remission if your university offers that as a benefit and go for a degree that will keep you interested.

alias454

First thing to to do is find out how to use the program you are going to be documenting. I wouldn't worry about your resume just yet. While you are using the program write down things that aren't obvious to you as an end user. After a few days of clicking on this and that. go through the entire process from start to finish. On each page where you are doing an action take a nice screenshot.

Learning how to do good technical documentation is a very valuable skill just because you aren't fixing someone's IE issue doesn't mean you aren't learning anything.

TheFORCE

Writing documents and making it user friendly is a very important skill have. You might not have it now but this is where you get to build the skills. Documentation is very important.
I used to write documents, guides and how to's when I was at the Helpdesk, that helped me become the lead of the team and 10 year later I write most of the Infosec guides, policies and procedures. These are documents that the entire company gets to read and follow. Thats not the only thing though, because of that, i'm able to translate the processes the business has into technical workflows which I get to implement on my solutions.

So don't think about it as something negative or as something that has no value, you are still new, you just don't know how important it is yet.

joemc3

coyoterey wrote: »

My main issue with documentation is that I'm getting close to zero guidance because no one here actually knows how to do it either. They just gave me the task and check in every two weeks (with different and contradicting advice). On top of this, I have no real world IT experience. Working on documentation is not giving me that experience, because I'm documenting non-IT related processes.

This is not me whining about doing a task I don't like. It's being concerned about my resume when all I can bring to the table is experience documenting education related material. I won't know how to setup a server, or fix a students technical problem. But I'll be an expert at telling you how your transcripts work!

Guide yourself! Also, the documentation is way better than doing helpdesk pushing tickets.This is an entry level job and you need to learn a lot about a lot. Do the job well and put it on your resume.

ITSpectre

Honestly learn how to document... because guess what..... Its not going away!!! It is better to learn it NOW then to try to learn it LATER. Think about this.... A hacker hacks into your network and uses a brute force attack to get login passwords for users and managers. You notice the threat because he fell for the honeypot that was on the network and he is trapped. You successfully find out, and prevent users passwords from being taken... now guess what? You have to DOCUMENT that.... Trust me, the help desk is really just going to give you the basic skills and you will be pushing tickets all day. The worst thing about the desk is repetition.... dealing with the same issue day in and day out and knowing most of the issues result because of user error....

Also lets say you need help troubleshooting a issue and there is no documentation on how to fix it and you figure it out.... you have to document that as well.... believe it or not IT is based around documentation ESPECIALLY the help desk...

ITSpectre

In IT when you are thrown to the wolves.... that is the time to really show people what you are made of. So what if nobody is helping you!!! We have all been there myself included. This is your time to shine and google is your best friend. Use this opportunity to learn everything you can about documentation and learn how to document properly. In my own life you can find out what a person is made of when they are thrown to the wolves. Trust me be glad you are experiencing this NOW.... Because there are going to be different jobs you may get in the future where "nobody knows much of anything" and since you have been there... you can excel while everyone else is scrambling because they don't have a clue either...

use your skills, reasoning, and trust yourself.... you can do this!

$bvb379

I agree with others in saying that documentation is very important. I am currently 2 months in at my first IT job and they have the "thrown to the wolves" approach to learning. I just google everything that I don't know or call co-workers. They have no documentation or procedures to streamline any processes so I am taking the initiative to create this documentation for new hires. I am not sure why this has not been created yet but I am not the owners or team leads.

For example, when setting up new desktops, you need to type in the correct credentials for Outlook, transfer the .pst file, and transfer the .nk2 file. I had no idea what these were, where to get them, or what they did. I pretty much had to go back after hearing complaints from clients because no one told me the procedure to setting up everything a client needs after setting up a new PC. Now that I know this information, I am writing some technical documentation so that if someone is completely green, like myself, they can have an idea of what needs to get done.

ITSpectre

$bvb379 wrote: »

Now that I know this information, I am writing some technical documentation so that if someone is completely green, like myself, they can have an idea of what needs to get done.

That is why Documentation is needed. It tells you what needs to be done and HOW to go about doing it.

If I told you OP to create 3 new users in Active Directory and 1 Administrator account.... and then create a group mailbox with the admin to have full ownership of the box but the 3 users could only read and see whats in the mailbox.... you could not do that without documentation on how to get it done correctly.

ThePawofRizzo

Even if you're documenting some non-It processes, learning to create good documentation is important and will be valuable.

A LOT of my documentation involves screenshots, AND I use SnagIt to edit the screenshots and enhance with arrows, numbers for steps, etc. In this way I can minimize writing. I use sections in a document I write and include a Table of Contents at the beginning. There are a lot of Wikis online that go over the basics of documenting workflow or processes.

Your first doc won't be your best. When you do the second document you may find better ways to do it, so you'll go back and touch up your first document. And so on. I often write a first draft, and have co-workers or users review it, even do the task with it, and get their honest feedback, then tweak the document as needed. If it's simply a process document it doesn't have to be fancy, just organized and understandable.

ITSpectre

Here is something that I learned in a meeting I was in today....

1. Infosec - Documentation. You will have to document pentesting done on a company network so they can see what you did, how it was done, and the vunerabilities on the network

2. Networking - Documentation. Network topologies are part of networking. If you are in networking you may have to document how the network is laid out, switches and routers, etc.... And make a network diagram

3. Project Management - Documentation. You will have to document and do project write ups... deal with clients, co workers, and upper management... that is part of documentation.

4. IT Management - Documentation. SOP's, emails, company meetings, etc.... all require documentation.

Documentation is part of IT... we may not like it, but we all have to do it in some form or fashion.

Remedymp

Policy documentation on certain topics can make you an SME.

YesOffense

Man, i'm not sure you quite grasp the weight of having the opportunity to create documentation for a new app/development, plus AWS, and where that could place you if done right. They must see something in you to give you that responsibility. Just be forthcoming with asking for help and do your research.

Trucido

I love documentation. I also love helping people. When you create documentation you help people that may not even be at the company yet. But 15 years down the road, if that problem still occurs, no matter how rare, other colleagues will be able to refer to your documentation and fix the issue! I like the way IT Spectre said it, really shows how each department can use documentation.

It can get you promoted, it can open new doors, but in regards to OP not knowing most of the How To things in the first place, that is probably the biggest problem. But at the same time, for most subject matter, google is your friend. Where I currently work, most of the knowledge we get (sad to say) that isnt in a Knowledge Article is from Google..

Then guess what? To make it more readily available to our colleagues, we reformat the information we found on Google to our needs and create a knowledge article on it! Woohoo!

I worked with a guy who was hired and within 6 months, due to all of the work he put in for Knowledge articles, was promoted 2 steps from Tier 1 to Tier 3 (supervisor) so yeah it can REALLY help you, and it helps everyone else who its available to.