Blame the IT Guy: Fear and Mistrust of Technology
Posted by 
Share this Post
Better collaboration can occur when users stop blaming the IT guy
Jim Harris recently blogged about The Road of Collaboration, making a case for the business and technology sides of a company to come together and walk the middle road towards greater collaboration. Although this joining of forces would be an optimal scenario, overcoming the fundamental prejudices that some non-technical people have against their technical counterparts makes it difficult to walk hand-in-hand.
When things go wrong on a project, as they inevitably do during development, testing, or – spotting Murphy's Law here – at some point in production, the first place most business users look to troubleshoot is within the technology. This theme is lampooned in another of Harris’ articles, the Pirates of the Computer: The Curse of the Poor Data Quality in which bad data quality gets blamed on the system, the process, and seldom on the user.
And why should it? After all, everything worked fine the day before and now it doesn't. Something outside of human error must have failed and this "something" naturally relates back to the hardware, the software, or some inconsistent gremlin that slipped into the servers to wreak havoc. Trouble tickets are opened, the IT support staff is called, and the resource-intense analysis that lasts for hours (or maybe even days) commences.
We all logically know that the technology is sometimes the cause, and sometimes it's not. We know that problems can and do come from where we least expect it or – heaven forbid – may even be due to us and our own fat fingers.
But even when knowing this, the first person users blame is the IT guy, or, barring that, the software application, which is really the same thing. Remarkably, this scenario occurs even when IT has minimal input into a product other than hardware support, such as a “buy versus build” solution where the vendor’s product is the real culprit of data issue.
So we must ask: why does the IT guy get scapegoated for these errors, guilty until proven innocent? Regardless of the real cause behind bad data, this process takes up time on both sides of the fence, causes frustration against "broken software" and "inept users," and leads to animosity that shoves collaboration out the window.
There are workarounds to this, but it's not easy. For starters, we probably need to understand why the IT guy gets the blame. Although there are many factors, two of the main sources seem to be Fear of the Unknown and Mistrust of Technology.
We talk about fear of computers (cyberphobia), which is really just fear of the unknown. Although not as common as in the past, it is particularly prevalent for those who are not familiar with computers and loathe the advancement of computers in society that shifts the way "things have always been done."
We all know someone who is reluctant to adopt new systems. New only complicates things, and people who are not comfortable with changing their old habits will reflexively jump at the first sign of trouble. To them, the culprit must be the new technology.
Similar to a fear of the unknown is a Mistrust of Technology in general. With news about viruses, constant hotfixes, and the overall chaos surrounding rushed product rollouts, it's no wonder that computer systems get a bad rap.
This is not completely unjustified. In a 2008 article on IT systems failure , software failures were cited as the number one reliability issue in an organization, followed by network failures, performance degradation and the failure of physical components.
All systems have the potential to collapse, seemingly without warning, so it's no wonder that the first place people point their fingers is the IT department.
With these factors in mind, organizational teams may be able to take some action. For example, to mitigate the fear of the unknown, users should be encouraged to become familiar with their software of choice through training, tutoring, online forums, and even one-on-one mentoring.
Overcoming the prejudice of unreliable technology is a bit more difficult, especially when users believe they have the hard evidence to back up these prejudices. The goal is to prevent finger-pointing so communications channels between the users and the IT staff should be maintained before escalation truly begins.
Sometimes the problem is a quick fix and that having an on-site dialogue can save frustration well in advance.
By turning our focus against the task at hand rather than blaming the IT guy, we increase the level of patience, open-mindedness, problem-solving and flexibility within a team. This can go a long way towards walking the road of successful enterprise collaboration and ridding the IT department of the curse that haunts them at every network failure.
4 Responses »
Leave a Response
Entries(RSS)
Great post, Jarrett!
(And not JUST because you referenced two of my recent blog posts.)
Gremlins have indeed slipped into the servers to wreak havoc, which is why you should never get them wet, always keep them away from bright lights, and the most important thing, the one thing you must never forget: no matter how much they cry, no matter how much they beg . . . never, ever feed Scapegoat-ius IT-Guy-ius after midnight
Maybe we should rename IT to IG (Information Gizmos)? Who could possibly be afraid of Gizmos? We could even start calling the folks who work there Gizmologists. Who could possibly want to scapegoat a cute, cuddly Gizmologist?
Okay, on a more serious note, although blame-storming can feel very cathartic, and sometimes, it seems like nothing brings a group closer together than when they are pointing their collective finger at another group, and IT makes an all too easy group to point at, blame-storming sessions don’t help the organization move forward, don’t help minimize the likelihood of similar incidents recurring in the near future, and don’t foster any true sense of teamwork (except among those on Team Not Our Fault).
Blame-storming is all about the traditional definition of CYA.
Forget that definition. Let’s redefine CYA:
Collaboration Yields Accountability
Collaboration yields accountability for both the collective ownership of the issues as well as the collective responsibility for resolving them.
Best Regards,
Jim
Nice analogy between Information Technology staff and Steven Spielberg's cinema Gremlins, Jim! And I have worked with a few (not many) "cute and cuddly" IT guys, just as you described.
There IS a strong temptation to scapegoat IT, software vendors, exogenous data sources, everyone and everything but one's own area for data quality lapses. However, there is an additional reason for focusing on IT staff. In some of the organizations where I've worked, the increasing reliance on RDBMS for program strategy support as well as performance and regulatory reporting has caused a shift of power away from the management, subject matter experts and operations staff, with control moving instead to IT.
The IT staff are gatekeepeers and guardians of the data, and even when all is going well, the scenario where IT effectively drives the business can develop easily. IT staff do not necessarily want this role, in fact they usually don't! But when it happens, it's difficult to shift back.
Any thoughts on how to solve or prevent this, Jim or Jarrett?
Hi Ellie,
Excellent point about the difficulties caused when IT becomes, or is perceived to become, the gatekeepers and guardians of the data. It’s as if the business feels like they are absolved of all responsibility for the data because they gave it to IT to manage for them.
I have seen this happen when organizations believe that if they simply load all of their existing data into a shiny new system, like say an enterprise data warehouse (EDW) or a master data management (MDM) hub, it will magically resolve all of their enterprise-wide data issues -- and if it doesn't, then IT must have screwed up the data when they loaded it.
Basically, instead of saying “you broke it, you bought it”, the business is telling IT that “you loaded it, you own it.”
However, this all comes back around to the perception of a deep divide separating the business side of the organization, who usually own its data and understand its use in making critical daily business decisions, from the technical side of the organization, who usually own and maintain its hardware and software infrastructure, which comprise its enterprise data architecture.
Although the business and IT both commonly operate as if they were independent of one another, the truth is that they are highly interdependent. The success of all enterprise information initiatives is highly dependent upon enterprise-wide interdependence—aka collaboration.
Best Regards,
Jim
I think the comments open up a great topic of discussion regarding whether we can truly rid ourselves of the prejudice that creates the "us" versus "them" attitude. I totally agree that the problem is with the ownership--IT (the Gizomologists!) own the hardware and the Business owns the data, and without proper data governance, the issue becomes a Catch-22. That is, if the Business wants to see their data, they have to get through IT hardware first and if IT wants to make changes to their infrastructure, they need to go through Business to understand the data. At some point, when something breaks, the prejudice comes full circle with both sides accusing one another, Usually the ones with the most at stake (the Business) have the loudest voice.
As long as teams wants to blame the IT guys and vice-versa, I don't believe true collaboraion is possible. To get over this, how do we overcome the misunderstanding and fear that creates the finger pointing? Whatever is decided should then be put into some sort of troubleshooting design. With a good process in place, we might be able to harness a lot more collaboration with a lot less frustration..
And, contrary to opinion, I do believe that feeding the IT guys after midnight should be allowed.
-Jarrett