Opinion by Paul Glen

Paul Glen: Techies and users are in a vicious circle of mistrust

We in IT like to complain that we don't get the respect, engagement and trust that we deserve. There's no shortage of outrage in IT departments about the low regard we are accorded by our business partners. They hire us and pay us good salaries, presumably because they consider us the experts on technology and its use in business. But they frequently exclude us from strategic conversations, make decisions without consulting us and ignore our advice. In response, we feel disrespected and untrusted.

When I ask nontechnical business people how they feel about us, they use words like "condescending," "confusing," "defensive," "evasive," "legalistic" and "excessively detailed." They recall bad experiences that have led them to be skeptical of anything that IT people say. They have gone through project failures, and at times they have been treated poorly and felt bad about it. Fair or not, you are emblematic of those experiences even if you had nothing to do with them.

But though they rarely mention it, they have one more reason to mistrust us: We don't trust them much either -- and they know it. We're not known for our acting skills.

Our lack of trust arises from the many negative perceptions we have of business people. When I ask technical people how they feel about working with "the business," they use words like "ignorant," "unrealistic," "aggressive" and "unappreciative." They say business people don't know what they want and constantly change their minds. We can recall our own bad experiences that have led us to be skeptical of anything that business people say. We have seen project sponsors shirk responsibility and shift blame, and just like the business people, we have at times been treated poorly and felt bad about it. And we make generalizations about business people based on those experiences.

It is very hard to trust someone who doesn't trust you. And since this feeling exists on both sides, a vicious cycle kicks in: They don't trust us, in part because we don't trust them, and we don't trust them, in part because they don't trust us.

It sounds kind of hopeless, but it doesn't have to be. Cycles can be broken with a little self-awareness and honesty. You just need to do two things:

Recognize your negative assumptions. If your sponsors changed requirements midway through the implementation on your last five projects, it's natural to assume that it's likely to happen again. Because you're a techie, and therefore good at solving the problems you recognize, you might incorporate something in your project process to mitigate the risk of requirements changes, such as demanding approval signatures on the requirements documents and imposing penalties for subsequent changes.

But that is likely to lead to a problem you might not recognize. Your new stakeholders don't know the history and just think you are naturally mistrustful, defensive or overly rigid and legalistic. And they feel mistrusted.

Share your feelings and concerns. Instead of making rules based on assumptions, you'd be better off telling new stakeholders that you feel concerned because of past experiences. Ask them to help alleviate your reasonable apprehensions. When you share your feelings, you demonstrate trust rather than mistrust. And in turn, they may expose their fears and concerns based on past experiences and give you a chance to help them.

What's the worst that could happen? If they don't want to participate in that discussion, then you have good reasons to not trust them and you're right back where you started. So you've got everything to gain and rather little to lose.

Paul Glen is the co-author of The Geek Leader's Handbook and a principal of Leading Geeks, an education and consulting firm devoted to clarifying the murky world of human emotion for people who gravitate toward concrete thinking. You can contact him at info@leadinggeeks.com.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies