As a professional speaker I often get asked where the passion comes from, my response is always the same, “People who speak passionately about a subject, are doing penance. They are attempting to make up for past transgressions.” That explanation sometimes gets a blank look in return, so I thought it worthwhile to provide some deeper background on why Change Management is my passion. Here’s the result.
I post it, with complete confidence that more than a handful of IT folks will recognize themselves.
Let’s face it. If you make your living in IT, then compared to most people you’re a God/Goddess. As techies, even dilettante techies like myself; our technical knowledge is so far beyond that of typical Homo sapiens, we’re almost an alien and often a hostile, race.
While intended as mostly tongue in cheek, this observation is unfortunately an accurate description of typical IT behaviour as we deal with the technically challenged. As techies we often have less empathy and sympathy for non-technical folks than we have for mosquitoes and other buzzing insects. This is particularly true when we attempt to implement new systems intended to increase organizational efficiency in some significant manner.
You can find the anecdotal data to support these opinions on any online forum where we techies gather to lament the daily ineptitudes of our end
losers users. If the audience for this article weren’t technical, then I’d provide a few URLs for your reading pleasure, but we’re techies and we know that Google is our friend, so I won’t bother. You’re smart enough to find the watering holes of user disdain on your own.
If anecdotal evidence is beneath you, if you prefer your data hard, and your numbers crunchy, then the Athabasca University survey project known as the “Canada IT Issues Study” (Google it) will satisfy your addiction to raw data.
Begun in 2000, they received more than 11,000 survey responses from IT professionals. The results unfortunately back up all the disparaging remarks I’ve been making about our industry. We’re not really very good at making our users, those that pay our salaries, feel comfortable with the systems we create and the change we mindlessly inflict.
According to the 2003 iteration of the survey; when asked what impact we have on our organizations, 41% of respondents believe that we (IT) increase employee stress levels throughout the organization.
Getting more specific, the survey asks how well we manage IT related change. In 2000, 27% believed we handled it well; in 2001 this rose to 37% and then fell back to 32% in 2002. In 2003 the number sat at 34%.
While the survey is admittedly a snapshot of Canadian IT perceptions and beliefs, I’ve travelled enough across this tiny planet to state confidently that IT attitudes towards end users and change management are the same the world over. With individual exceptions duly noted, we’re cut from the same cloth. We don’t focus our efforts on managing the change we inflict. We’re technically savvy and revel in our arcane and elite knowledge to the detriment of those we’re mandated to assist.
At the root of this mismanagement of change is that to us, technical knowledge is second nature, while to our users, it is literally an alien language. The change management problems we encounter aren’t directly generated by this knowledge gap, but by how IT practitioners chose to address this inequity of understanding.
Based on my own growth towards understanding this thing called “Change Management” here are some of the mistakes I’ve made and the lessons I’ve learned over three decades in this industry, and since I’ve used ‘I’ a lot … I’ll continue the trend.
Sadly, I wasn’t always aware the gap existed. I assumed that everyone I spoke to understood “technology” as well as I did. I don’t notice when the person I was talking to stopped listening and or their eyes glazed over. I was totally oblivious to the lack of communication taking place.
Browse the forums I mentioned earlier and you’ll find an over abundance of disrespect directed at those who don’t “get” technology. Admittedly some of it is hilarious — I’d be disingenuous to claim otherwise. Appreciating slapstick humor is a human quirk and beating ourselves up because we laugh at banana peel jokes is pointless. We Laugh. Get over it. As long as my humour remained a private vice I was okay, but when I allowed it to negatively affect my client relationships then I deserved to fail.
When I did become aware of the gap, I didn’t pay it the respect it deserved. I figured that if the listener just tried harder, or if I spoke louder and slower, that they’d get it. Needless to say this was the wrong approach. I failed and my clients were increasingly frustrated.
After I became aware of the gap, I still considered it to be their problem, not mine. My belief was that I was paid to build and install new systems and nothing more. That the whole process of getting users to actually use what I’d created was someone else’s problem. I was also peeved when applications I’d slaved over to deliver on time and on budget, were ignored and later moth balled. I never realized that the solution was mine to seize, at the time I wasn’t smart enough. I’m much smarter now.
Life would be so much easier if I didn’t have to wait for others to catch up! Why can’t everyone understand this as well and as quickly as I do? Why do I have to wait while they learn? Or worse yet, why do I have to be the one to teach them to use what I’ve built? I wish I could say that those thoughts never belonged to me, but instead all I can offer is that I grew up and grew a tad wiser.
Technically there’s usually a right way and a wrong way to solve a problem. It took me far too long to recognize that technical considerations are not the only important aspects when solving a user problem. Business considerations, usability issues, cost factors and even aesthetics are all equally, if not more, important. As a techie I always had all the answers, even when I was ignoring the questions.
I’ve my own way of learning. When approaching a new technology I’ll skim the manual to find out “what can be done”, and pay no attention to “how to do it”. My memory is (was? Sadly I’m older now) good enough to lead me back to the exact page necessary when I needed to do something. I absorbed the broad brush strokes of technological concepts and ideas. I expected everyone to learn the same way I did. I allowed no deviation from what worked for me and puzzled over why this frustrated my clients and why their knowledge wasn’t advancing.
I worked hard to upgrade a user’s system to the latest version of their primary application. It increased their capability ten-fold. I expected gratitude from them for making their lives easier! What do I get? Complaints and whining! Discontent with this and that! Don’t they appreciate what I’m doing for them? It took me a long time to appreciate their point of view that I hadn’t done anything “for” them, but I’d done a lot “to” them. For starters, I’d taken away their status quo, their competence, usually without asking their permission. The result? Totally unnecessary resistance to change brought about more by my attitude than by the technology.
“But it’s just common sense!” the naïve techie cries in frustration as a user fails to get what the techie considers so obvious that it defies teaching. That naïve techie was myself, not just when trying to introduce a user to a user to a new application, but long before that in my university days when trying to explain Differential Calculus to a class mate. It takes time to learn something important and even a techie will agree that learning something new is important. My assumption was that this was easy for everyone. It wasn’t, and still isn’t. Pushing them only caused them to push back. I was creating my own problems because of incorrect assumptions.
Pretty much sums up how our users see us. Given some of the sins listed here, who can blame them?
Change is difficult. It can’t be managed. Users will never understand what we’re trying to do, so why bother trying? These are the perspectives of a technical problem solver who’s given up on common sense. It’s a short sighted, career limiting vision. Granted, people problems are far more difficult than technical problems, and there’s no ready manual to read, but they’re not impossible to solve. It just takes intelligence, patience and a desire to solve difficult problems. Things we pride ourselves on quite often.
Finally I became, not only aware of the gap, but I recognized that as the person who designed the new system, I was also the person best positioned to get people to embrace it. There was one small problem. I had no clue how to get people to move willingly from an old way of doing things, to a new, improved and better way.
That’s when my job became Interesting.
A much shorter version of this rant appeared in the January 2006 issue of Computing Canada. It is reprinted here in the longer version with their permission.