Are you a technical writer who is struggling to interview SMEs? Are you frustrated that your work is seen as a necessary evil rather than something that adds value to the product? Then this ‘How to Interview SMEs’ article is for you.

Interviewing Subject Matter Experts (SMEs)

Interviewing Subject Matter Experts (SMEs)

 

What? You Don’t Even Know That?!!

Yes, I’ve had that said to me. On more than one occassion. So don’t worry, you are not alone – most of us technical writers will be scoffed at at some point. Especially if you are an out-and-out technical writer rather than a techie who has tried to turn their hand to writing. When it happens, you can feel all sorts of things, ranging from humiliated and out of your depth (I felt like this in the early days of my first job) right up to enraged  (I’ve felt like that too!). Clearly, feeling this way isn’t going to make you a productive and effective writer, so with this article, I’m going to give you a few tips that I have picked up while working with technical people and…how shall I put this?…let’s say people with unusual personality traits.

1. Leave your Ego at the Door

If you are a technical author, you should not give two hoots what SMEs think of you. Yes, you need to get on with them (at least professionally) so that you can work together, but you don’t have to try and make out you are an aspiring technical expert. In fact, if you start using their terminology and jargon, you run the risk of becoming an ineffective technical writer, especially if your audience aren’t as tech-savvy as the SMEs.

The only people you need to worry about are your readers.

Our profession isn’t really respected by many technical experts. To them, it is just writing the obvious. That’s something you need to get used to. On the plus side, if you create good manuals and online help, you can get techies on-side a little, especially if the documentation has resulted in them getting less queries from other staff and customers.

2. Don’t Embrace the Jargon – Avoid It!

Use language and terms that mean something to you when dealing with SMEs. It will help you process the information they are providing more quickly and effectively. Use the same language in your notes, but also jot down the correct jargon terms. Over time, you may find that you become more used to the jargon terms, which is fine when dealing with SMEs, but never lose sight of that first day when you didn’t understand them – you need to remember that lack of familiarity as it is something your readers may experience too.

Not using the ‘correct terms’ may result in certain SMEs looking down their nose at you, but you have to learn to shrug that aside. The SMEs may have this notion that you are supposed to be a technical expert, but that’s wrong – you are there to represent the perspective of the customer. Learn to love being sneered at! It means you are doing your job right. If it helps, just say to the SME that you find the jargon term a little too abstract to take in, so you like to think of it in different terms . If you say ‘hey, that’s just how my brain works’ the SME can’t really argue, can they?

When it comes to actually writing the documentation, you will need to judge whether using the jargon makes things easier or more difficult for customers. To do this, you have to figure out whether customers use the jargon terms all the time, and are comfortable with their meaning. Quite often, any customer-facing staff will be able to help you with this (customer support, projects engineers, etc.).

If removing the jargon makes the documentation more difficult for readers to understand, don’t remove it (as it is ‘normal’ to the end-users). If customers don’t use those terms, ditch them. To try and cover both camps, you can try and explain what is meant by the jargon term in the first instance it is used. But only do this in the section that is primarily about whatever the jargon term describes – if you do this everywhere, the documentation will become awkward and possibly patronising too.

3. Don’t Waste the SME’s Time

This is really important. If there’s one thing that is likely to annoy SMEs a lot, it is asking them the same questions over and over again. I know, because I’ve done it.

In some companies, SMEs are under a lot of pressure due to time constraints, so you’re not going to be flavour of the month if you waste their time. When you get the opportunity to sit down with an SME, make sure you can use every minute of their time effectively:

  • Make a list of questions about the product, feature etc., before your meeting.
  • Take time to think through the sort of problems users may face when dealing with these features. Sometimes, other questions can pop into your head if you imagine you are actually trying to use the feature rather than write about it.
  • Get a notepad and check that your pens are working. If you can get a dictaphone, that might help too, but you probably have to get permission to record anyone these days. Is a video camera/phone overkill? You decide!

If you work in a team of authors, keep an eye on what the other writers are doing. Sometimes, different areas of the documentation overlap, so you may find that another author has already asked the SME about something you are writing about. If so, try to get the information from the author first, as SMEs also get annoyed if two people from the same team ask the same questions. Which is understandable, I suppose.

4. Respect the SME’s Workload

If your boss is on your back about a documentation deadline, it is likely that you’ll want to see an SME immediately. But that doesn’t mean you can demand it. No matter how tight your deadline is, the chances are that the SME is also up against it. So if they say they are too busy to see you, don’t get frustrated – just explain the situation calmly. They may not have realised you were under pressure, and now that they know, they might be able to juggle things around to help you out. If not, then you both have a problem, but it is not your fault or the SME’s fault. All you can do is go to your manager/client, explain the situation, and leave them to sort out the priorities. If that means you and the SME have to go see the powers-that-be together, so be it.

The important thing is that you don’t get too wound up about the SME being busy and try to force the issue with them. I have seen technical writers being quite forceful with techies and it has caused animosity that has lasted far beyond the end of the project.

5. Stay Calm and Don’t be Late

When you do get a chance to see an SME, arrive in a calm state of mind. Remember, you might be on the receiving end of a sneer or a couple of sarcastic comments when you are asking ‘dumb’ questions. If you are stressed, you might be confrontational without even realising it. Before the meeting, take a few minutes to get calm and mentally prepared.

6. Don’t Be Afraid of Admitting You Don’t Understand

Do not nod your head and say you understand if the reality is that you are still not quite sure. This goes back to leaving your ego behind – there is nothing wrong with ‘not getting it’. Sure, the SME may snigger at you, but you’ve got to learn to cope with that. Put it this way, if you don’t, and you just pretend you understand, you’re going to get it wrong in the documentation (or it may be technically right, but sorely lacking in the details users need). All that means is that you are going to look like you can’t do your job very well. And that’s much worse than feeling like a dummy for a few minutes, right?

If it makes you feel any better, I’ve had to say ‘I’ll have to stop you there. I don’t follow what you are saying.’ on a product I had worked on for over 10 years.

It can also help if you explain why you don’t understand. In one of my previous jobs, one SME often said to me ‘But that’s basic maths’. The first time that happened, I thought ‘Oh God, I’ve been found out. Maths was never my strong point and now it has come back to haunt me.’. The second time, I wondered if I should swot up on mathematic terms. The third time, I just explained to him that I scraped a C at maths at school and had forgotten everything except basic addition, subtraction, multiplication and division. I also let him know that my A levels were in non-science subjects, like English and Art and Design, and my degree was in technical communication. From that point on, he was much more forgiving when it came to the maths-related elements. He would still say ‘that’s basic maths’, but it was without the ‘you should know that’ connotation. Now it was more – ‘you would have known that if you didn’t waste your time at school studying the works of Matisse’.

7. Relax. Don’t Do It

Never lose control and blow your top at an SME (or anyone else at work, for that matter). If an SME is giving you a hard time, perhaps by making your struggle to get to grips with a feature a little more public than you’d like, just try and laugh it off. Granted, it is not always easy, but if you can laugh at yourself, you can diffuse the situation and save yourself a lot of grief.

Also, if there are other people around when you’re struggling to understand something, don’t assume they are all laughing at you. The chances are that they are thinking ‘I’m not sure I understand that, either’ or ‘why doesn’t he/she explain it in a different way?’, but are reluctant to join in.

8. Be Judged on your Output

It’s not easy being a technical writer, but hopefully the points I have made so far will help you when you’re trying to get information from technical experts. Remember that your reaction to the situation is just as much a part of the problem. If you can inject a little humour, explain what you are struggling with, and why you are finding it difficult, things might just start to work out better. You might even be seen as less of a chump for a while (no promises though, that’s never happened to me). But the real test is when you produce the documentation – if you have done it the hard way, asked all the right questions, and persevered when you just couldn’t get your head around things, your work should be all the better for it. And believe it or not, when people see that your documentation is actually useful to customers and staff, they will look at you in a new light.