How to interview an SME

There are four of us who all came from the same place. We've known each other since the Dow was at 900 and for the past two decades have pitched in on each other's writing projects. Last week, Doug was preparing to train a team of technical writers and felt that he was lacking good ideas in one of the areas he was supposed to cover, which was "how to handle interviews." So he sent an email to the other three of us asking "how to draw out essential material from SMEs under the normal constraints of time and availability." Within 90 minutes, John had responded with this:

1. Get a recorder...and a phone patch cord--and make sure you know how to "get bars" to indicate that the recorder is actually working. I would never trust my note-taking to capture the nuances of interviews (especially on technical subjects).

2. Get as much background as you can about the subject ahead of time, and sketch out some questions based on the background.

3. Take notes...even if you're running a recorder. It's often helpful to have a "visual" clue at your fingertips, reminding you of what's been discussed...so that you can ask follow-up questions, or return to key topics later in the conversation.

4. Don't try to fill up the silence: If somebody's thinking, let them think. Let them pause...in order to elaborate. A well-placed "um" or "uh-huh" is often enough to let them know that you're still there, engaged and listening.

5. Engage in enough small-talk to put the interviewee at ease...but don't waste a lot of time on it. If you're in two different cities...and you know that the other place just got a lot of snow, or their team won the Super Bowl, use that sort of detail to create a civil, engaging tone to the conversation.

6. If you need additional detail or background, ask for it. It's OK to ask what an acronym means, for example. Usually, you'll get more useful information if you play a little dumb, rather than trying to prove to the SME how smart you are.

7. If, during the course of an answer, you learn about an existing PowerPoint presentation or white paper, ask for a copy of it.

8. Respect the SME's time. If you promised to end in 30 minutes, then try hard to do so--setting a followup time if you still need to get more info after your "window" is up.

9. Expect the SME not to respect your time. Count on them being late for the call...and don't schedule another call to follow immediately thereafter.

10. Check your recorder immediately after the call, to make sure it was working. That way, if it DIDN'T work, the topics you talked about will still be fresh in your mind, and you may be able to cobble together enough written notes to save your butt.

11. Most of the above tips also apply to face-to-face interviews, and with one addendum: Make eye contact. It's OK to look away to take notes, etc....but don't stay buried in your notes. Treat the interview like a conversation.

Laurie was on vacation at a beach in Mexico, but three hours after John, she had added her tips:

1. Get a digital recorder. In four years, I have not suffered a malfunction (knock wood), and it's great to have a backup file of the interview on your computer.

2. Get approval ahead of time from the moderator or SME to record the interview. Explain that it dramatically increases the accuracy and time efficiency of the entire project.

3. During the interview, when you hear a key topic, jot down the time stamp from the recorder. Afterward, you can zip right to that point.

4. Download to your computer and transcribe ASAP. A foot pedal helps immensely.

Interview questions (if these apply to technical writing)...

Ask the SME:

-- "What is the most important thing that (the audience, users) should know about this (topic, product)?"

-- "Who are the different types of people likely to use the product?"

-- "What are the benefits to each type of user?"

At the end of the interview, ask: "As a hypothetical exercise...if you had to put a headline on this (story, product description), what would it be?"

I wanted to go last, hoping that all my points would be covered and I could just respond: "what they said." But in the end, I was inspired to add something of my own. Ten minutes before midnight, I sent my list:

1. I like to start an interview with as broad a question as possible and then avoid asking another question as long as possible. Like this: "Wow, cloud computing...what's your story on that?" And then shut up. The point is to see where they will voluntarily go with it. They might talk for 10 or 15 minutes if you don't stop them, and that tells you what's important to them, and the order of importance. As they talk, of course, clarifying questions will occur to you. Write them down. When they finally run out of steam, you can then say: "Back when you were talking about total cost of ownership, you said something I didn't quite understand..." If you ask questions during the flow of their initial answer, you break their stream of consciousness, and you'll never get it back.

2. This sounds so elementary, but it requires discipline: As soon as someone says something like "There are three keys to this initiative...", you have to start counting. You don't want to go back and listen to your digital recording (you are using a digital recorder, right?) and only have two things, or not be able to tell where #2 ended and #3 began.

3. I think of the interview in four parts: #1 is the broad opening question that they can take in whatever direction they want to go. #2 is the clarifying questions you wrote down while they gave you their stream-of-consciousness answer. #3 is the questions you wrote down in advance, some of which will already be answered, and some of which you now need to ask. And #4 is a fishing expedition. I have some favorite things to ask here. One is, "So was there a moment in this whole thing when you knew this was actually going to work?" Often there was, and their answer gives you the turning point that helps you turn information into a story. Another question is: "Through this whole experience, what was your biggest surprise?" They'll usually stop and think about it, because the question intrigues them. You have to keep quiet while they think. Their answer will frequently be something that also contributes to the narrative. Another one I like is, "I can see that you really changed this (process, function, environment, etc.) but how did it change you?"

4. With a group of SMEs, don't work toward consensus too soon. Keep them in the question as long as you can. I'm actually kind of bad about avoiding consensus at all. Sometimes I don't want them to tidy up all the loose ends, because I don't trust them to come up with a better conclusion than I would on my own.

5. Don't settle for abstract answers. Make them tell you what actually happens. You say, "So walk me through this. A guy comes into your bank with an idea for a dog-walking service. What does he say? What does he know? Where has he been before he got to you?"

Years ago I worked with "the worldwide competency leader in knowledge management" at IBM. He defined knowledge like this:

Knowledge is a fluid mix of framed experience, values, contextual information, and expert insight that provides a framework for evaluating and incorporating new experiences and information. It originates and is applied in the minds of knowers. In organizations, it often becomes embedded not only in documents or repositories but also in organizational routines, processes, practices, and norms.

Yeah, that's what we did, my friends and I, emailing through the afternoon and night, knowers telling what they know in a way that offers a framework for a new generation of technical writers to use as they strive to more quickly and competently do what they're asked to do.