As content developers, we work with subject matter experts whose knowledge we’re going to translate into something executives will want to read. Many are a pleasure to work with. Some aren’t. But it’s always critical to establish a productive working relationship.
Some authors and experts are excellent collaborators. Most people who have published previously understand that a story is developed, not dictated, and there’s an art and a process to do so. Others are resistant to help. They cling to what they want to say in the way they want to say it, whether or not it’s the best way. Most people fall somewhere in between.
We ran a workshop recently with a dozen or so of our writers about strategies for quickly establishing a good rapport with an SME. Here are their recommendations.
Establish your expertise from the start…
The author is an expert on the topic, but you are the expert on content development. Refer to yourself as a content developer, not a writer, so they know you are not there to take dictation. If you position yourself as a thought leadership content development expert (or however you choose to describe it), your expert will get that that you have skills and knowledge they do not. That makes you a collaborator, not someone to be told what to write and how to write it. This will make the difference between a good story and an indifferent one and between a good working relationship and a poor one.
and your credentials
Send a LinkedIn invitation to the SME before your first call so they can understand who you are and the qualifications you possess. Have someone else, such as a colleague or their marketing person, introduce you, stressing your experience and expertise. Do the same for your team members. Recap your relevant credentials, name-dropping as appropriate. And if you have shared professional or industry expertise, let them know you speak a common language.
Make it easy for them to participate.
Be prepared for the first call and the interview. Read the author’s bio so you don’t have to ask questions to which you really should know the answers. Look up previous articles your author has written. Reference something from those articles to show you’ve done your homework. If appropriate, send questions in advance so they know what you’re looking for.
Lay out the process for developing their paper or article in that first call. Explain the timeframe, the purpose of each step, and when and in what form you’ll need their input. Help them understand what you’ll need to help them: knowledge, opinion, and their experience supported by case examples. Also, explain what you won’t need, such as a draft of the article.
Establish a rapport.
To help the SME develop fresh content, you must know their field well enough to have a conversation about it and understand what’s been said before. If you don’t, decline the assignment, at least until you feel you are up to speed. Otherwise:
- The author won’t be inclined to view you as a collaborator.
- You won’t, in truth, be able to tell the difference between original insight and received wisdom.
- The author will be justified in thinking he should tell you what to write and how to write it.
If you know what you’re talking about, you can make intelligent observations and suggestions, and the author will allow you to help him shape his story.
You can’t win them all.
Sometimes, nothing works. You can’t help everyone every time. Your SME may not allow himself to be helped. He may decline to provide examples and insist on a point of view that has no chance of being published. In that case, your goal shifts from writing the article to preserving the relationship for a future article.
Don’t get into a fight. There are polite ways to suggest a restart. For instance, you might say, That’s fascinating, and if you can come up with some client examples, we’ll have a super article. Praise always defuses defensiveness. And, perhaps, your SME will go back to the drawing board and find a new idea, or he may drop the whole thing without thinking you’re a jerk. Count that as a win.
Not every story ends happily, but it doesn’t have to end badly.