IT Staff vs. Non-IT Staff: Cant We All Just Get Along?

I've worked with IT people for a long time, so there was an air of familiarity as I read the dilemma Roger Canada related on the Never Work Alone Google group:

'I was in a meeting with my boss the other day and we got on an interesting topic, IT staff and their inability to relate to non-IT staff when tech issues arise. As you may hear, see and even do, it is common complaint in our line of work to hear, of IT staff members when explaining or demonstrating a situation to a non-IT staff members glossing over important steps or moving to quickly through material. So my question is this:

Do you have any suggestions on how - if possible - IT staff can be taught to more easily relate to non-IT staff?  I work in a university and I find here the staff are broader in style and demographics than you would typically find in an organisation such as IBM which only compounds the situation between the two groups.

This resulted in a number of responses, which tended to cluster around two common themes:

1. Observations on why the relationship between IT people and non-IT people are strained, and
2. Suggestions that may make it easier for these two groups work together.

This issue spurred a number of good ideas and observations about some possible factors that contribute to this kind of "communication gap."

Why do they have trouble getting along?

A number of comments related to some of the dynamics that make it difficult for IT and non-IT people to communicate effectively.

Personality styles can get in the way

Scott pointed out that IT people tend to be introverted, which contributes to them being more likely to miss subtle “social cues.”  He went on to explain that IT people (programmers in particular) are more task
oriented, focusing on technical issues at the expense of big-picture issues.

Jargon and communication styles exacerbate the gap

Jeffrey related his experience that the use of acronyms can have a distancing effect, and we all know IT is rife with acronyms.  However, as Jeffrey pointed out, even non-IT people are guilty of this and cited his CFO’s use of terms like “EBITDA” as an example.  He noted that the use of stories and analogies are far more useful when conveying technical concepts to non-technical people.

Some of this is rooted in social skills, some in ego (”I’ll speak over your head so you’ll feel inferior.”), and some has to do with different thinking styles (visual / non-visual, data vs. feelings, etc.).  A friend of mine who worked with high-tech companies on Myers-Briggs Type Indicator testing indicated that these companies had a much higher percentage of ISTJ’s (Introverted, Sensing, Thinking, Judging) than the normal population distribution.  This type doesn’t lend itself to naturally empathetic interactions.

Another observation I’ll add post-facto is that there is something strange about how non-technical people view IT problems: they often blame themselves.  If you use a non-IT product and it doesn’t work effectively, you blame the product.  On numerous occasions, however, I’ve heard people having trouble with software say things like, “I must be stupid - I can’t get it to do what I want it to do.”  Bizarre phenomenon.

Why not seat them together?

JC offered the suggestion that the two factions sit together, and pointed out that "This is the generic solution for helping two groups relate to each other. Increase the opportunities for serendipitous interaction.You may end up with something like a school lunchroom, where everyone is in the same place, but in their own little group.”"

Scott commented that this solution may not work very well for IT, “…since programming is a solitary task. Programmers tend to keep to themselves, or only relate to other programmers…The drawbacks could be huge, especially if you are moving people away from their other coworkers, who they need to have instant access to. You may end up with something like a school lunchroom, where everyone is in the same place, but in their own little group.”

Scott’s observations are consistent with my own.  In one company I’ve worked in, our IT team was seated in cubes adjacent to an inside sales team.  This drove the IT folks crazy, since the Sales people were on the phone all the time, were kind of loud, and talked about sports a lot (our IT people were more into Babylon 5, Halo, and X-Box mods).

Scott made a great observation that seating them together could work if they were all working together on the same, cross-functional project.  Since IT people are “task oriented,” this shared project ownership would allow them to have a task-centric relationship which could be a very good thing.

So what else can you do to help the situation?

Improve your user interface

Several posts related to establishing a more user-friendly interface between the IT team and the rest of the company.

I mentioned that, in companies I’ve worked in, we've had success in hiring a bit differently for the roles that are the "liaisons" between our more technical sysadmin / netadmin staff and the general user population. For these roles, we look for people who have a good grasp of technical concepts, paired with the desire / ability / history to be able to explain technical concepts to non-technical people, display more patience and empathy in their
dealings with others, and the ability to cover the basics without getting annoyed.

We also look for "problem solving" mentality (not necessarily technical problem solving either - just people who enjoy solving puzzles). These people tend to ask more questions like "what were you trying to do when this happened" and other things that get to the zen of the issue, vs. the specific "right" technical answer.

Michael Langford had some solid suggestions in this area:

• When hiring, place a premium on being able to explain technical issues to users and determine whether they've mastered the material. Expect this to cost more.
• Offer raises for taking training in oral technical communication
• Offer "days off" learning the essential business function of the department. You don't understand what they do, they often don't really GET what you do either, nor why its important - gieve them a chance to understand each other
• Train non-IT staff to repeat back in their own words what the IT person explained to them and confirm that they got it right (a good idea for any complex communication)

I’ve also seen great success in creating “self help” documentation in the form of Word docs, help pages on an intranet server, and even recording screen cam walk-throughs of common tasks (like adding printers, logging into the VPN, changing passwords, accessing email from home, etc.)  If you have someone in your IT team with good written communication skills, this can be a valuable way to capitalize on that skill.

Learn from best known methods

Mike Sale suggested considering a process framework like ITIL (The IT Infrastructure Library), because:

1. It is VERY "service", customer and user focused  It drives the "customer" to clarify what is important to them, and how important it is (Service Levels, Financial Mangement, Continuity,
   Availability, etc)
2. Best practices and structure that are proven and valued in the industry that are fiscally responsible, and measurable
3. You'll develop processes and practices that provide stability, continuity and reliability of services It shows that you're developing and managing a professional IT Service organization, and you don't just have "IT Staff".

As Mike points out, the goal of building “...a team that provides outstanding service and innovation to the customer that they can consistently show makes a measurable difference in the user community's productivity and
satisfaction.”

Mike also points out that, “This may mean a HUGE shift in the direction, composition and leadership of the organization/team, but I think you will find that iterative, deliberate implementation gives you the framework to manage and measure the success of the team through "customer satisfaction" and a way to put some wood behind your commitment to this group an important player in the success of the school.”

Summary Points

• Successfully improving communications between IT and non-IT people is much easier if you identify or hire empathetic people within the IT team to act as liaisons with the rest of the organization. 
• Encourage the IT team to spend more time on issues and use analogies and stories rather than technical jargon and acronyms.  Try to determine what they were trying to do, rather than simply focusing on the error message or specific problem they encountered.
• If you seat technical and non-technical teams together, consider whether they have compatible working styles.  It’s also beneficial to try to align their work around common, cross-functional objectives or projects so there is less conflict.
• Consider learning from best known methods like ITIL to develop a stronger service orientation within the IT team.
• Reward your IT team for actions and improvements that make the situation better such as non-technical communications training; spending time to work with the users to better understand their working challenges; creating useful, reusable documentation; etc.

---

Acknowledgements

Thanks to Roger Canada, J.C. Yip, “screaminscott”, Michael Langford, Mike Sale, and Jeffrey Phillips of Thinking Faster for their fantastic participation in this hot topic. You can find the blow-by-blow details of this topic on the Never Work Alone group on Google.

Dwayne Melancon is the author of the Genuine Curiosity blog.

Comments

[Tban]

Acknowledging the worth of many of the observations in respect to improving IT/Non-IT relations, after 20 years in IT, I think the crux of it is in the perceptive observation:

"there is something strange about how non-technical people view IT problems: they often blame themselves. If you use a non-IT product and it doesn’t work effectively, you blame the product. On numerous occasions, however, I’ve heard people having trouble with software say things like, “I must be stupid - I can’t get it to do what I want it to do.” Bizarre phenomenon"

Yes it is a phenomenon, and as such it is worth a closer look. Where does this attitude come from, how is it maintained (because it is persistent and very widespread), and what are the implications of it?

I'd suggest that the attitude expressed 'clasically' as "I don't know anything about computers" has been largely created and maintained by IT service deliverers because it puts them in a position of 'power' in relation to the IT consumers. It is much easier to 'get things done' when nobody questions you, and it is flattering to be called a guru.

But how does a small group of IT people persuade a much larger group of IT consumers to adopt an unflattering view of their own capabilities? Because the proponents of IT technology have had an inordinate amount of power in organisations in the last 25 years. And because it 'suits' IT consumers to avoid to some degree taking responsibility for their IT environments.

To save time in psychological explanation, consider someone you know who says "I can't drive a car, it just something I can't do". Then consider what you have already concluded lies behind that - some trauma (perhaps) or more likely some shrinking back for taking responsibility.

When those attitudes are reinforced by virtually every interaction IT consumers have with IT service deliverers, they can be remarkably persistent. I'm not suggesting that IT techs abuse customers to their faces (although some do), but even the politest rarely respond to the "I don't know much" with "yes you do, and if there's something that you need to know that we haven't taught you then it is our fault, and lets do something to fix that."

The consequences of this mutually satisfying (if largely unconscious) relationship are damaging to the organisation. The IT people having determined that IT consumers are to blame for 'everything' are effectively denying themselves the opportunity to recognize opportunities to improve the IT enviroment (because you have to take responsibility for something before you are motivated to fix/improve it); while the IT consumers are foregoing a (potentially) huge boost in productivity through failing to be given/demand/take-up opportunities to use IT in 'cleverer' ways to drive their companies business.

My problem with ITIL is that it takes a process (and forms) based approach - which are good things in themselves - but fails to recognise individual and organisation dynamics which are often 'irrational', but nonetheless 'real' and therefore need to be dealt with via real world strategies.

So how do you fix this unhealthy relationship. My suggestion (and here I'm skating on thinner ice because I've only ever succeeded at this 'to a small degree') is to challenge the belief in the the minds of the IT people everytime and everywhere you encounter it.

IT people have one particular weakness (generally) and that is that they are strong on logic. So I like to ask them, when viewing some balls-up, "so whose fault - ultimately - was that?"

Take the cleaner unplugging the network power in order to run their vacumn cleaner .. "so whose fault was that?", "Yours, because it shouldn't have been plugged in anywhere where anyone unauthorised would have access to, and it should have been a 'captive' plug (basically difficult to remove) and it should have been labelled".

Logic, with some folk, will win over prejudice. If you can get your IT techs to 'take this on board' all you have to do is get them to tell the IT consumers what's actually happening and they too will start taking their IT responsibilities more seriously.

Oddly enough, you'll get more respect from IT consumers by admitting that things are "the fault" of IT, and you'll find that it's easier to fix those things because the IT consumers will be 'coming along with you' as allies rather than enemies.

You know, they say that the best thing to bring together people who don't get along with each other is some 'common enemy'. Well we don't need to invent one, we have one ready-made, it's the sorry state of our IT environments, and our common cause can be to improve it and in doing so drive our companies business, our job satisfaction, and our skill levels ahead.