The Technical Expert’s Handicap
Peter de Jager is a provocative Speaker, Writer and Consultant. His primary focus in on how we manage change, technology and the future.
In addition to speaking at conferences worldwide, he's also written monthly columns for Municipal World and Computing Canada.
His goal is always to question what we think is so, and in so doing perhaps open up new opportunities.
If you'd like permission to reprint any of Peter's articles, please contact him directly.
You can contact him at
pdejager@technobility.com
Or sign the Guest Book and he'll get back to you.
Knowing the solution to a problem before others are even aware of the problem, is deemed by technical experts as concrete proof of their elevated technical expertise. Fair enough. Unfortunately from the user’s perspective,
solutions - seemingly disconnected from the issue at hand - lack credibility and are deemed unconvincing.
Ironically, just as the user had a nonexistent understanding of the original technical problem, the technical expert is oblivious to the people problem of
the credibility disconnect. To put it as simply as possible the technical
expert has two responsibilities a) find the solution to the problem, and
b) to convince the client/customer/stakeholder that this solution is the
right one. Those who don't deliver on both of these responsibilities are
not the experts we should be working with.
From the technical expert’s perspective, they have solved the technical issue and they can now move on to the next challenge. That the user will not learn anything from the expert, will not follow their advice, and will not deploy the solution, is not even
perceived by the expert as a problem. They are totally blind to the people problem they’ve left behind them. If, on rare occasions they are aware of it, they respond with: “Convincing the user I’m right, is not my responsibility!”
This divide of understanding between technical experts and the common user is all too common; one need only look to today’s headlines to see examples of its consequences. After Hurricane Katrina, official after official made the statement, “Nobody could have ever imagined that the levees could break!” They make this denial despite reports detailing the consequences, down to the depth of the flood waters intersection by intersection, throughout the drowned city of New Orleans.
When this denial of expert opinion proves to be the worst possible action, the deniers have a ready made - convincing to some - excuse and rationale for ignoring expert advice: “How could they possibly know which expert to listen to? Experts don’t always agree! Other experts disagreed with those worst case scenarios!”
At first glance that does sound convincing. Experts don’t always agree and the user is, by definition, not knowledgeable enough to select the correct answer out of a labyrinth of differing expert opinions.
One can counter that argument with the suggestion that with Murphy in mind, responding to one of the more dire reports might have been the most prudent course of action. Certainly preparing for some adversity is more prudent than sticking our heads in the sand and assuming that our sacred status quo will prevail.
There’s another way to respond to the user’s, “Experts differed, I didn’t know which to listen to!” argument. Rather than use it as the user’s excuse for inaction, we can use it as strong evidence to suggest that experts consistently fail in their appointed duty to solve problems…
A problem is solved in two steps: first we find a solution, then we implement it.
As technical experts, folks in IT are very, very good at the first step of finding a solution. Regardless of the challenge, we can bring
the mighty weight of technology to bear on it and come up with something that will work. It might be expensive, it might be cutting edge, it might be complicated, but it will work.
When it comes to the second step, it’s not that we’re poor at it; it’s that for the most part we don’t even accept that it is our responsibility.
This raises the question: If they (the users) aren’t convinced by our presentation of the solution, and if we don’t see the need to overcome this lack of “buy-in” (I hate that term… I’ll save the reasons why for another rant article), then who exactly is responsible for solving the problem? Not just identifying the solution, but actually implementing it and removing the problem?
The pushback on this notion that the technical expert is responsible, not only for coming up with solutions, but also for their successful implementation, is to be expected. Those who insist they are not responsible for successful implementation are welcome to stick with that viewpoint. Those who embrace the notion that implementation is part of problem solving will have the almost unique experience of seeing their ideas put into to practice.
Put another way? There’s no satisfaction in predicting the flooding of New Orleans, and seeing it come to pass from a paddleboat. There’s great satisfaction in predicting a flood and then walking on dry land.
© 2006 Peter de Jager – Yes, he's a speaker with a passion for Change. You can contact him at pdejager@technobility.com
For
reprint permissions click here.
I'd appreciate reading your comments
regarding this article... please take the time to respond.
Resources: