The 7 sins of user support

Look no further than the 2024 IT marketplace, where the best paying jobs are predominantly technical, and attributes like strong communications and soft skills are all too often deemphasized. It’s no wonder that IT professionals spend their time honing their technical skills, and then end up speaking in technical acronyms that few people understand.

Staff “technospeak” with users is a familiar user support issue that CIOs have faced for years. CIOS always want to improve the communications skills and user outreach of their staffs, but too often, they find that their top performers are poor communicators. At the same time, the external IT marketplace often makes it challenging to find, reach, and pay more for “soft skills” people who have the relationship building skills critical to working with users.

Given these realities, what are the “seven deadly sins” of IT user support, and how can user support be improved?

Talking down to and marginalizing users

A typical scenario provides a sin by omission: A tech-oriented person such as a network specialist goes to a user area to resolve a network issue. The user patiently waits at his or her desk, the technician works to resolve the problem, and problem solved, the technician, often without saying a word the entire time, gets ready to leave. Naturally, the user wants to know what was wrong.

I’ve known IT professionals in this role who’ve answered the user’s question with an unintelligible, grunted response, or have spit out an acronym like “AD lockout,” which means nothing to the user. Intimated, the user stops asking questions.

There is lasting impact from this. Users feel marginalized, and they don’t feel they can communicate with IT, which can introduce future problems for the organization and leave the IT department poorly perceived by business colleagues.

Failing to communicate at all

Equally damaging is a failure to communicate at all. This can happen in the previous example if the tech simply fixes the problem, moves on, and doesn’t even notify the user that the problem is fixed. It can also happen if a bug is reported by a user, IT fixes it, and no one ever notifies the user that the bug has been fixed.

The user hears nothing about a bug they have reported, so the user finally calls IT. IT says, “Oh, we fixed that bug last Wednesday.” The user wonders if they ever would have known that the bug was resolved if they hadn’t followed up and called IT themselves.

Here, lost productivity in not knowing that a service or key workflow issue has been fixed is an organizational problem. Plus, as above, this kind of behavior can erode confidence in IT’s reliability.

Omitting training from projects

A new system is installed and goes live. There is some cursory training just to get users started with the new system, but few tasks in the original project plan address training in any great detail. The end result is that users stumble around with the new system, often learning by trial and error, and the IT help desk gets inundated with calls. This causes delays in user support.

It can be argued that it is not really IT’s responsibility to train the business basics of a new system, but if IT is developing the project plan, which it often does, training should be included as a major milestone with project activities in the same way that software development and installation are.

Not developing and testing for usability

As a rookie systems analyst, I once inherited the task of making a dairy ration system usable. This system was best in class for formulating dairy rations, and the developer was an absolute mathematical algorithm genius. Unfortunately, users refused to use the system because it was too complicated to use.

We streamlined the GUI and developed it into a dashboard. Then, we cut away multiple levels of click-through screens to simplify the workflow. Within six months, all 26 user sites were using the new system.

The lesson gained from this project was that software usability matters. Unfortunately, few IT QA checkout routines have a box that is checked for usability. Ease-of-use should have equal billing with bug resolution and functionality checkout in QA and in all phases of application development.

Not understanding and empathizing with business pain points

User problems and requests are best addressed when you thoroughly understand both the business and the business pain points that the user is experiencing. In my CIO experience, I have often found the IT staff lacking in business acumen and in the ability to listen to or empathize with end users.

If you are a business analyst, your approach should be to view your internal users as “clients” whose satisfaction must continually be earned, and not to take them for granted simply because everyone works for the same company. Few CIOs stress or expect this, but they should.

Failure to build relationships at the user and middle management levels

One important daily task for the CIO is to circulate among user management so that strong working relationships can be formed and maintained. It is these cooperative relationships that provide solid foundations for project cooperation and success. Many CIOs fail to do this. Instead, they bury themselves in desk work or in internal IT meetings.

The staff members and middle managers in IT look to the CIO to set an example, so if the CIO fails to build relationships with users, it’s likely that IT staff will follow suit. The net long-term effect is that underdeveloped relationships can render it more difficult to build cooperative, collaborative, and communicative work teams with end users, or to gain their managers’ support for projects. This can endanger project success.

Not focusing on strong security habits

If anything has been learned in IT project development over the past few years, it is that security must be an integral element of every software, hardware, and network implementation that IT performs.

Users continue to be a major source of security breaches. This has caused IT and internal regulators to call for more social engineering audits that check for security exposures in end-user departments.

The end users can view social engineering audits as intrusive, so it’s important for IT and internal auditors to explain what the security risks are that they are trying to minimize, and how social engineering audits can reduce that risk. IT should also present user security checks and assistance as a user support activity. Regular new employee and employee refresher training in security should be conducted by HR and IT as part of overall enterprise risk management.

Final remarks

Supporting end users is a paramount task that should be at the top of every IT mission list. By treating end users as clients who deserve support and consideration throughout each project life cycle, and in the daily activities that involve IT, IT can forge strong working relationships and cooperation with end users, which turn will produce more successful projects and collaborative work.

Everyone wins in an environment like this. But CIOs must elevate user support to the status of an IT mission. A CIO does this by stating it in the IT strategic plan and by practicing what they preach.