Thursday, February 18, 2010

What makes experts expert

In my previous blog I throw some (well-padded) elbows at experts, and Isaac Rabinovitch rightfully takes me to task a bit. He makes the points that sometimes the gnarly explanation is needed--true, see my post on G2G (Geek-to-Geek) communication--and that technical communicators should not cut off experts during their explanations.

My comments were directed as much to us when we acquire expertise to be mindful of how much our listeners need to know (readers, friends, and family all included). Issac's comments do raise the important issue of how should we interview SMEs and then what is our role to our readers as surrogate SMEs?

Components of expertise

OK, let's the get the obvious out of the way: knowledge. JAVA experts know a lot JAVA syntax and stuff. Historians know a lot of events and dates. That's the easy part.

Studies of experts have discovered that experts see patterns that non-experts do not. For example, athletes talk about being able to "see" the court or the field. Part of why Payton Manning can call such effective audibles is that he can see the patterns in the defense (whereas you or I would see 11 people). When I taught electronics, I would like to start the week by showing a typical schematic we would be dealing with that week and ask the students to estimate how many components there were. The answer was typically "hundreds." At the end of the week I'd ask the question again and the answers were more realistic (20-30). What changed? The students now saw the schematic as a power supply, pre-amp stage, and amp-stage. They saw the patterns and that helped them process the previously overwhelming details.

Another thing research has shown about experts is that their knowledge is tacit--they no longer know what they know. They draw on their knowledge so instinctively they cannot observe their processes. I tried to document a couple of my Dobro picking patterns for a friend and it was HARD! Not the transcription and notation part, but just being able to slow down and see what I did instinctively.

So part of our job as communicators is to help SME's uncover their tacit patterns so we can pass those along to our readers. In that way, we start to transfer expertise instead of just information.

I remember once interviewing an expert and asking what a good starting value was for a particular variable. "It doesn't matter" was all he would say. So I finally said, "OK let's start with a million." In about five seconds we arrived at 35 is a good starting value. After that, it was just "When would you make it bigger? When would you make it smaller? How would I know if it were too big or too small?"

And this isn't just about technical writing. We are all SMEs at something. I've started writing music down and it's forced me to investigate the tacit patterns I've been applying. It's made me a better player and will enable me to be a better teacher if I can ever get one of my grandkids to take up an interest in Hootie's hillbilly music :-)


Ted said...

Not an objection really, more of a quibble, but this isn't quite right: "JAVA experts know a lot JAVA syntax and stuff. Historians know a lot of events and dates. That's the easy part." That's the hard part. Historians aren't really about events and dates. The expertise that they apply is about the meanings of things that happen or don't happen, the ways people perceive and interpret those things, and how that causes other things to happen or not happen. They end up knowing a lot of events and dates, but only as a side effect of the real value they generate. In fact, many of the Java engineers I know, being engineers, make it their business to know a whole lot of events and dates, and are glad to hold forth on them over a beer. How well they're equipped to make any sense of them is another question. Which I guess just reinforces what you're saying, so I'll shut up.
Except: I just tried and failed to count the times I've had that conversation about the value that "doesn't matter," until you throw out an absurd figure and the engineer spits out his coffee, whereupon we find out that it really does very much matter. That's why I love this job.

Michael Hughes said...

I think we are in agreement, Ted. When I said the dates and events were the easy part, it is because seeing the meaning and relationships behind the events is the value add (and the hard part). I just wanted to point out that in addition to their insight and expertise, experts "know a lot of stuff" about their field.