Technical people are not usually known for their people skills which means we often need some extra help in that area. Being eager learners though, it is a skill that we can learn in order to overcome the obstacles we face. For this entry, I want to examine one particular relationship situation. What can we do to build relationships when we are new to an organization? All groups go through a four-stage process called Forming-Storming-Norming-Performing. A group can move both up and down the scale which is usually triggered when new people join or when new issues or opportunities present themselves. An organization is going to exist in one of these phases before you join, and your addition could cause it to change.

As IT professionals and managers, we usually reached our position by showing a good degree of technical proficiency. However, we may not have to show a lot of people skills in order to get where we are. This panel at the campus IT professional conference for the University of Illinois was put together to help guide IT professionals on relationship management. It was nice that the campus has the sorts of resources to record events like this because it means other people can get a chance to hear it.

Watch and listen to Tom Kunka, Chuck Thompson, and me talk about the relationship side of IT.

IT people have a bad reputation from most end-users. End-users often see IT people as arrogant and outright rude. Having worked in IT for the last ten years, I have seen enough of my peers do exactly the things that perpetuate those perceptions that I can see why end-users dislike dealing with us. Being treated like a lesser human being does nothing to develop trust or keep communication going. So what can IT people do to make things better?

The Obvious
To most people, some things are obvious in how you deal with people, but sometimes we still need to be reminded. You want to be helpful without being patronizing or talking down to the end-user. Yes, they may be doing something that you think (or that they even admit) is completely stupid, but you should never say or do anything to let them know what you're thinking of their computer aptitude.

Be as patient as possible, and listen to what the user has to say. You may immediately know what the problem or solution is, but there may be a key piece of information you need to get from them to be sure. Some users have a harder time explaining the problem they are having so it's important to give them a chance to fully explain what they are experiencing before you start getting into a solution.

Try to gauge their ability to understand any solution you implement, and explain it in their terms. If you do not think you can explain the solution in a way that they will understand, describe what you can and be honest with them about the rest. The fact that you are trying helps the user know that you are interested in helping them learn.

The Not So Obvious
Be honest about when you will get to the problem or when you think the solution will be complete. If it looks like you won't get to it when you said you would, tell the user and make sure that letting the issue sit on the back-burner for a bit longer will not keep them from doing work. If the end-user can not do the job they need to do, you need to get to fixing the issue as soon as possible. However, any honesty you can give them about when you will work on their problem will keep them on the happier side of the spectrum.

One thing I have found that is very effective at keeping a positive relationship with end-users is to follow-up on problems I have fixed. While an e-mail suffices, it is not the best way to follow-up. The best follow-up I have found has been catching a person in the hallway or stopping by their desk and just asking if the solution you implemented is still working. The extra bit of face-to-face communication goes a long way to making a user feel like you are truly interested in helping them. It also gives you an opportunity to find out about issues they are more nervous about bringing to your attention.