Yes, I’m serious. You are not doing your job properly. Your goals are wrong, your approach is wrong, your methods are wrong, and your complaints about your job are mostly due to situations you created or contributed to. Hold your arguments, defenses and rotten tomatoes until the end.
What’s the Problem?
I get to say these things because I did it wrong for longer than I’d like to admit… probably most of my career, actually. I’m sure I still fall into the old habits sometimes and just don’t notice. It’s not about a lack of knowledge, ability, or potential. It’s about a misalignment of focus.
Why did you get into IT? Was it because you always felt something between a strong interest and an outright fascination with computers or electronic gadgets? Did it have to do with an enjoyment of tinkering with broken things and getting them to work? Did you see an opportunity to work directly with the guts and wiring (whether hardware or software) and change the way it works? If these are even remotely related to why you got into IT, then this is why you’re doing things wrong.
Have you ever started a trouble ticket or problem description with something similar to: “The user is trying to use Word and…”? Leveraging your training and experience, you set out troubleshooting a Word problem. You most likely came up with some solution that allowed the user to overcome the particular barrier s/he called you about and everything came out OK. In that case, you arrived at an acceptable ending – but with the wrong approach.
The evidence is more clearly seen in all the other cases – when you can’t fix the problem immediately or perhaps at all. Keeping with the Word scenario, there may be a software defect or it could be that the user typed “paper airplane” into the page and expected a fully formed paper airplane to fly out of the printer. The user ends up frustrated and upset, you end up frustrated and upset, one or both of you tell your friends and colleagues a funny or mean story at the other’s expense, and the rift between IT and everyone else grows.
To get a better view of what happened, go back and look at the phrasing of the problem description. It’s completely incorrect. The user isn’t trying to use Word at all. The user is trying to produce a document (or something). Word is just the tool s/he happened to select for the task, and for whatever reason, it’s not doing it. The user has called you, not to get Word fixed, but to get a document created. Whether you get Word to make it or wave a magic wand and have it pop out of thin air, the user would be equally satisfied. If you ended the call and the user had no document and all you did was talk about and work on “problems with Word”, then you did not address the user’s problem, and that is why s/he is unhappy.
The underlying issue is that technicians got into their field to work with technology, but that isn’t IT’s scope (or at least, it shouldn’t be). The purpose of IT is to make it easy for the organization to achieve its goals. Note that the only time “technology” appears in that sentence is in “IT”. IT does generally leverage technology to satisfy its purpose, but that’s not always true; IT must be flexible enough to know when technology won’t be appropriate and be able to communicate that. IT staff must be able to look beyond a simplistic problem report to the desired outcome and chart a path to reach it. That extends well beyond the front line help desk: users don’t want a highly available Microsoft Exchange topology; they want to be able to reliably communicate with customers, coworkers, partners, and vendors. Executives don’t want to know the details of SuperAwesomeTech’s Supreme Dashboard Software; they want to quickly assess what’s going on in the organization without lots of phone calls and meetings. This even extends beyond computer/network/software architecture and support; Joe Bob doesn’t care about 120hz 1080p, he just wants to be able to see the game in the best picture his money can buy.
Why Should I Care?
IT seems to have gotten along just fine this way, and companies seem to be surviving, so what’s the big deal? The big deal is that IT is largely disconnected from the rest of the company, at least in appearance. Part of that is from learned behavior; IT is usually only called upon when something isn’t working, so they learn that interacting with non-IT staff is a Bad Thing™. This results in IT gaining a reputation for being antisocial (and sometimes, it’s because they are antisocial), so the rest of the organization somewhat avoids them.
The gap between IT and everyone else is the source of most of the reasons that IT and everyone else share a mutual discontent. If something is down and can’t be fixed right away, IT will often tell the end user that the issue will be worked on and the user will be contacted when it’s fixed; users can’t see into IT, so far all they know, nothing is being done. They also might believe that if IT was doing its job properly, the issue would never have occurred in the first place (and sometimes this is true).
If the perception of the IT department leads to a widespread attitude that IT doesn’t care or is incompetent, this can lead management to be reluctant to invest in the IT department. Who gives raises to underperforming staff? Who buys into projects for a department that has repeatedly shown it doesn’t properly utilize the money that it’s got? Who listens to people who don’t listen to others? Again, these positions may be founded upon misperceptions, but that’s entirely irrelevant. What’s important is that these are real attitudes and conditions and they are why so many in IT are disgruntled. The unhappiness IT feels toward everyone else and vice versa generate a vicious cycle that can easily spin into perpetuity. It’s up to IT to realign its goals to match those of the end users, fix its methodologies, and correct its image.
In the next part of this posting, I’ll look at what steps can be taken to address the situation…