A Portrait of the Data Quality Expert as a Young Idiot
Once upon a time (and a very good time it was), there was a young data quality consultant that fancied himself an expert.
He went from client to client and project to project, all along espousing his expertise. He believed he was smarter than everyone else. He didn't listen well - he simply waited for his turn to speak. He didn't foster open communication without bias - he believed his ideas were the only ones of value. He didn't seek mutual understanding on difficult issues - he bullied people until he got his way. He didn't believe in the importance of the people involved in the project - he believed the project would be successful with or without them.
He was certain he was always right.
And he failed - many, many times.
In his excellent book How We Decide, Jonah Lehrer advocates paying attention to your inner disagreements, becoming a student of your own errors, and avoiding the trap of certainty. When you are certain that you're right, you stop considering the possibility that you might be wrong.
James Joyce wrote that "mistakes are the portals of discovery" and T.S. Eliot wrote that "we must not cease from exploration and the end of all our exploring will be to arrive where we began and to know the place for the first time."
Once upon a time, there was a young data quality consultant that realized he was an idiot - and a very good time it was.



Jim Harris
Reader Comments (6)
Ah! the fallacy of the ONE RIGHT ANSWER to all projects, all organizations, all environments, etc. I've met that guy a million times...and he isn't always young...but he is always an idiot.
The older...er...more experienced I get, the more I realize that real world problems don't have simple questions and they certainly don't have simple answers.
Jim,
My experience so far in my career has taught me that what is more important than knowing the right answers is knowing the right questions to ask...
...and those questions need to be the ones that shed light on the questions that the company/client needs to have answered.
How long is a piece of string? Well, what do you need the string for?
Nice post. Note to self... must up game (again)
I think the "a Little Knowlegde is a Dangerous Thing" phenomenom is a subset of this. I've been subjected to several implementation partner experiences where the "expert" has a a very narrow range of experience and exposure. When you couple this with a "right at all costs" attitude you get some interesting results.
My first performance appraisal in my first job was:
"Shows an arrogance and over-confidence not yet born out in technical ability"
That was pretty humbling and since then I've always tried to remember the proverb that "experience is what you get one second after you needed it" and have always tried to keep these failings in mind. Not always sucessfully, but I try.
Great article and something to constantly remind yourself to be prepared for your own paradigm...the only caveat is that you must not fall into the trap of second guessing yourself.
How reflective! Nice post Jim.
I am also reminded of a couple of definitions for expert
1. A drip under pressure
2. The guy from out of town
3. In a court of law, the person in the court with the most knowledge on a particular subject
One of my own errors has been injecting expert knowledge too early in the project life cycle, e.g. speaking of data source issues during the requirements gathering phase and thereby cutting short non-technical discussions that might have led to a more robust business view of the desired data.
I try now to be more mindful of the task at hand for each phase in a project, trying to avoid a rush to design considerations during the analysis phase. This is not an easy balance to strike when a project team is working under a tight deadline.