Working with SMEs
Without losing your mind.
The Writers’ Table — article 4A.
Last year I spent three weeks trying to get a short meeting with an engineer about a webhook feature. He canceled twice, ghosted a third scheduled call, and on a Thursday night sent me a Teams message with four paragraphs of rewritten copy — none of it matching the style guide, none of it aimed at the users who’d actually read it. He was trying to help. It didn’t help.
If you’re a technical writer, you’ve had some version of this experience. The SME who doesn’t have time to review but does have time to rewrite your draft from scratch. The one who marks up every sentence but hasn’t looked at the user persona document you sent. The one who agrees to a 15-minute call and then cancels it across consecutive sprints.
Working with SMEs well is one of the most important skills in this profession. But it isn’t taught. You’re just supposed to figure it out. Now, let me make this clear. In over 30 years, I’ve had difficulties with maybe three developers/SMEs. Judging from some of the posts on Reddit and Mastodon, I might have been lucky. Here are some things to know.
Why SMEs Are the Way They Are
The first thing to understand is that the difficulty isn’t personal. SMEs are experts in their domain. Writing documentation is not their domain. It’s not how they think about their work, it’s not how they communicate internally, and in most cases it’s not a skill they’ve developed.
That disconnect creates two consistent patterns. First, when SMEs write, they write for peers who already know what they know. The result is expert-to-expert prose that leaves users behind. They’re not writing badly. They’re just writing for the wrong audience. Second, when SMEs review, they often optimize for technical accuracy without considering usability. They’ll correct a term and introduce a sentence that no user could follow.
It’s not malice. It’s the natural result of asking someone to evaluate content for an audience they don’t understand and aren’t a part of.
The incentives make it worse. SMEs are usually judged internally on shipping features, not on documentation quality. Every hour they spend reviewing your draft is an hour that doesn’t show up on their own performance review. Understanding that isn’t an excuse for ghosting you, but it explains why review requests consistently lose against anything with a sprint deadline attached.
Preparing for the SME Interview
The quality of information you extract from a subject matter expert is proportional to the quality of your preparation before the meeting.
Don’t walk in and ask “can you explain how this works?” That question has no scope. You’ll get either a lecture covering things you already know or a dismissive “it’s all in the spec” and thirty seconds of their time.
Walk in with a draft — even a rough one, even a wrong one. A draft gives the SME a specific target. “This is what I have. Here’s where I’m unsure. Can you confirm this part and explain that part?” That’s a different conversation than starting from zero. It respects their time and focuses the meeting. It shows that you’ve tried to meet them on their turf.
Prepare specific, observable questions. Not “how does the auth system work?” but “when a token expires, what exact response does the API return, and what should the user do next?” The narrower your question, the more useful their answer.
Asking Stupid Questions Safely
Part of the SME relationship is managing the knowledge gap. You need to ask questions that reveal what you don’t know, and some SMEs react badly to what they perceive as basic questions.
Two approaches help. The first is framing the question as user advocacy: “I understand how this works, but I want to make sure I can explain it to someone who doesn’t. Walk me through what happens when...” This shifts you from “writer who doesn’t understand” to “writer representing users (customers) who won’t understand.” Most SMEs respond better to the advocacy framing.
The second is being specific about what you do and don’t know. “I understand the token is JWT-based. What I’m not sure about is the refresh flow.” This establishes your baseline and limits the question to the actual gap. You’re not asking them to start from the beginning; you’re asking for the one piece you’re missing.
Handling Hostile or Dismissive Feedback
Some SMEs will tell you your documentation is bad without telling you what’s wrong with it. “This doesn’t capture how it actually works” is a common review comment that means nothing you can act on. It’s dismissive and useless. There’s nothing you can react to or fix.
When you get this, ask for a specific example. “Can you point to the sentence that’s inaccurate?” The problem is often narrower than the criticism suggests — one term is wrong, one step is out of order, one piece of context is missing. Get to the specific before you respond to the general.
When feedback is genuinely contradictory across SMEs, say so explicitly. “I received conflicting guidance on this. Denise says X, Bogdan says Y. I need a decision before I can finalize this section.” That’s a scope problem, and it needs an owner before you can proceed.
Building the Relationship Before You Need It
The best SME relationships aren’t built in the review cycle. They’re built before you have a request to make. A five-minute check-in that isn’t attached to a deadline, a genuine question about something you’re curious about rather than something you need for a document, a note thanking them when their review actually caught something important: these cost nothing and change how your next urgent request lands. An SME who’s had one good, low-stakes interaction with you is far more likely to make time when you show up with a real deadline. Treat the relationship as ongoing, not transactional, and the transactional moments get easier.
And don’t forget to treat it as a relationship between equals. Don’t grovel, don’t be a supplicant. And forget the advice about bringing cookies or brownies to a meeting.
Further Reading
On the SME relationship specifically
Write the Docs, “Conquering imposter syndrome” — the “Dealing with knowledge gaps” section is the closest thing the field has to a standard on asking SMEs basic questions without apologizing for them. Free, short, and it argues that not being the expert is an asset.
Krista Van Laan, The Insider’s Guide to Technical Writing (XML Press, 2022) — the practitioner’s guide to the profession, including how to prepare for an information-gathering interview and keep a busy engineer on topic.
JoAnn T. Hackos, Managing Your Documentation Projects (Wiley, 1994) — dated on tooling, still the best treatment of what happens when SME review becomes a schedule dependency instead of a favor. Relevant if you’re the one explaining the slipped date.
On the surrounding system
Jared Bhatti et al., Docs for Developers (Apress, 2021) — written by practitioners from Google, Stripe, and Monzo; useful on structuring review so SMEs are asked for technical accuracy and not line edits.
Write the Docs, “Building documentation mindshare in a company” — the org-level version of this article. If your SME problems are actually incentive problems, start here.
Google, Technical Writing courses — free, aimed at engineers. Worth knowing about mostly so you can send an SME a specific lesson instead of feedback they’ll read as criticism.
What You Can Do
Think about an SME relationship that went well and one that went badly.
Write one sentence identifying what made each work or not work. What would you do differently?
Next time: Review and Approval Workflows — how to move a draft from “submitted for review” to “published” without losing six weeks and your sanity.