The Goal: Not Being That IT Guy

Yesterday I was forced to call the support line for one of our vendors.  I hate doing that. I recognize that it's a weakness on my part.  I'm of the opinion that software vendors make their software in such a way that an individual such as myself should be able to address any issue without vendor support.  Call me naive.  What I'm discovering is that for industry specific software there is not a deep body of knowledge on the Internet and so bringing in the vendor is sometimes required (1).

In any case, we had a license hung up in the license manager and after searching and trying a couple of solutions that didn't work I was forced to contact the vendor.  *sigh.  I made a call because it's a fairly urgent issue (we only have one license of this type and it can't be used by ANYONE until the issue is resolved).  During the call I was asked a whack of questions.  Fair.  Some I could answer because they were environmental but some couldn't 'cause they were tied to my coworker's workstation - which was currently being used to make money for the company.  

During the discussion I was asked, "Are you sure you clicked on the <whatever the license type was> before you entered the release request?".  There was a bit of a pregnant pause whilst I decided how to answer that question.  Who am I kidding:  "Sir, if it was that easy do you think I'd've called you?"

Yeah, yeah, yeah.  An important part of any troubleshooting endeavor is eliminating the iD10t errors.  But we'd been talking for a while.  I presented as an IT professional and had a whack of information (including the error message of attempting to reproduce the error).  It's frustrating to be asked, "hey!  did you try to actually do what you want?" as part of the basic troubleshooting.

So here's my issue.  Read the room. As an IT guy I work with a wide variety of individuals.  Some of 'em are tech savvy.  Some, not so much.  It's my job to tailor my approach, questions, and explanations to the knowledge of the person I'm working with.  I know I don't always get it right (to be honest, I tend to lecture on proper terms and struggle to make technical concepts easier for folks to understand).  But here's the deal.  It's MY job to make technology accessible to my coworkers.  My job is to make their job easier through technology.

And here's the rub. It's so easy to be condescending.  It's so easy to be pendantic.  It's so easy to offend.  Even without trying.  But that's the thing.  IT folks need to work extra hard to not appear smug, know-it-all, or superior.  We are not superior.  We just have a specialized knowledge base.  We're employed because of that knowledge base but we serve at the pleasure of our coworkers.  We have to read the room and modify how we present our knowledge based upon the person right in front of us.  The person.  Replace that noun with "customer".  When you're in an IT role at a company, what you have to really understand - I mean really really understand - is that every one of your coworkers is a customer.  You have to modify your behavior to accomodate that fact.  Your coworkers are your customer.

The Customer is Always Right

Well, we know this isn't always true.  I think it'd be better to say that the customer always needs to be listened to.  How an IT person responds to their coworkers really determines the success of the IT department.

Returning to the matter at hand: Every day I am faced with coworkers who have issues.  They express them in the best way they can.  I need to take what they give me and work to address their issues.  Sometimes it's enough.  Sometimes it's not.  Here's my mantra:

1. Don't ask stupid questions:  If you can figure it out with out asking the coworker, don't. (This is the one that spawned this post, FYI)
2. If you don't need it, don't ask for it.  (This is a common IT approach, ask for lots of logs and the like to delay resolution).  If  you need it, fine.  But there's probably a 100 things you an do before pulling logs.
3. They are not users.  They are coworkers.  They are customers. Treat them thusly.
4. Technology is hard.  Not just for other folks in the organization but for me as well.  The difference is what level of technology is hard.  There's a spectrum of knowledge and folks who are amazing project managers may not understand how Sharepoint works.  That's okay and totally understandable.  I am there to help them with what they don't know.  They could totally school me on stuff I don't know.
5. There's nothing elite about being in IT.  In most companies it's actually quite the opposite.  Yeah, sure, IT has a lot of perks: Working remotely, access to info, influence on business operations but it's tempered with the fact that IT serves at the pleasure of the business.
6. Do not assume knowledge.  On the flip side, don't be pendantic.  Unless there's a compelling reason to ask a really "stupid" question, don't.  Assume knowledge and modify that level based upon what you learn from experience with your coworker.  If they don't know what you're talking about they will ask if you're doing your job right.
7. Drop knowledge but don't lecture.  Most of the time folks don't require the details.  They just want their stuff to work.
8. Don't keep secrets.  Everything IT does should be documented.  Not everyone needs to have access to that info but it should exist.  IT should be transparent. You serve the business.  If it isn't written down it doesn't exist.
9. Technology is a tool.  If the tool isn't working as desired it's broken.
10. If the tool is hard to use it's not a tool.
11. In regards to 9 and 10.  The job of IT is to make 9 and 10 go away.  Tools shouldn't be broken and they should be reasonably easy to use (2)

I could go on.  And on.  There's a whack of nuggets of wisdom I could expound on and I probably will.  I guess the short version is this: IT exists to make the lives of our coworkers easier through technology.  That's it.  Requiring hoops and scripts and stuff to address issues that demean our coworker/customers is inimical to a successful relationship between the IT Department and the business.  Don't be that "guy".

(1) I recognize that some of my past roles I had access to the internal documentation so I wasn't forced to contact support for these kind of esoteric issues.  I'm looking at you EMC and IBM.

(2) Complex tasks are complex tasks.  Some software is going to be complicated because what it does is complicated.  The software should always make a complicated task less so.  If it's not the case look for a new solution.