How to Get Time Poor SMEs to Give You Information, Then Actually Review the Document

Every technical writer hits the same wall eventually.

The document is 90% done.

It just needs 1 subject matter expert to confirm a few details, then sign off.

That expert is a senior engineer with 40 meetings a week, a system outage to manage, plus 3 other projects asking for the same thing.

Your document sits in their inbox for 5 weeks.

This isn’t a writing problem.

It’s a stakeholder management problem wearing a writing costume.

🤝 Rapport does more work than any template

People make time for people they know.

That sounds obvious, but it changes how you approach the first contact.

Don’t open with a document request.

Open with a short conversation about what they’re working on, what’s landing on them this month, what usually goes wrong.

You’ll learn 2 useful things from that.

  • What their real capacity looks like
  • Which parts of the process they actually care about

Once someone believes you understand their world, review requests stop feeling like admin.

They start feeling like helping a colleague.

🎯 Two ways to gather information, both valid

There are broadly 2 approaches to collecting content on a project.

The first is a showcase or walkthrough, where you present a draft to a group.

The second is individual sessions with each SME.

They suit different situations.

A group showcase works well when:

  • The process crosses several teams
  • You need people to see each other’s part of the flow
  • Decisions need to be made in the room
  • You’re close to final, needing confirmation rather than detail

Individual sessions work better when:

  • You need the exceptions, workarounds, unwritten rules
  • There’s a seniority gap that keeps people quiet in groups
  • Teams quietly disagree about how something works
  • The SME is genuinely time poor, so 15 minutes alone beats 90 in a workshop

Most projects need both.

Start individually to get the truth, finish with a showcase to lock it in.

⏱️ Strategies for SMEs who have no time

This is the practical part.

Assume your SME has 10 minutes, not an hour, then design around that.

Send a draft, not a blank page.

Never ask someone to explain a process from scratch.

Write your best guess first, using old documents, system screens, whatever exists.

Then ask them to correct it.

Correcting a draft takes a fraction of the effort of creating one.

Ask 3 specific questions, not 20 general ones.

Put the questions in the email body, numbered, answerable in 1 line each.

Something like whether approval sits with the team leader or the manager after hours.

Specific beats broad every time.

Use highlighted review, not full review.

Yellow highlight the 6 sections you actually need checked.

Tell them plainly they can ignore the rest.

Most SMEs stall because a 30 page document feels like a 2 hour job.

Show them it’s a 10 minute job.

Book the review, don’t request it.

Put 20 minutes in their calendar, share your screen, walk the document together.

You’ll get sign off inside that meeting rather than waiting a fortnight.

This single change fixes more review bottlenecks than anything else.

Record the session, then write it up yourself.

Let them talk while you take notes.

Never ask an SME to write content.

Writing is your job.

Give a real deadline with a real consequence.

Vague deadlines get vague responses.

Try something like needing comments by Thursday so it can go to the steering group on Friday.

People respond to a reason, not a date.

Offer a default.

Tell them if you don’t hear back by Friday, you’ll publish the current version as draft, then update later.

It’s respectful, it removes the guilt, it usually gets a reply within a day.

📋 Make review easy on the eye

How a document looks affects whether it gets reviewed.

A wall of text signals effort.

A clean layout signals speed.

A few things that consistently help.

  • Keep sections short, with clear headings
  • Put a summary of what changed at the top
  • Number the paragraphs so feedback can point to 1 place
  • Send 1 document at a time, never 4 at once

🗣️ Talk to everyone, not just the assigned SME

The person named on the project plan isn’t always the person who knows.

The real expert is often 2 levels down, doing the work daily.

So talk to the team leader, the new starter, the person handling exceptions.

New starters are especially useful, because they still remember what was confusing.

Collect from several people, then take the merged version back to your senior SME for confirmation.

That way your formal reviewer only has to say yes or no.

✅ Keep the relationship going after sign off

Thank people properly, in writing, where their manager can see it.

Tell them what happened to their input.

Send them the published link.

Small gestures like these mean the next request lands differently.

You stop being the person chasing a review.

You become the person who makes their team look organised.

That reputation is worth more than any process you’ll document.

Read More

Related Posts

🤝 Process Maps and Work Instructions: Why One Without the Other Falls Over

There’s a familiar moment on transformation projects. The maps are finished. They’re clean, colour-coded, signed off by the steering committee. Everyone agrees the new process makes sense. Then go-live arrives, and someone in the operations team asks a simple question. “Okay, but what do I actually click?” The map can’t

“We’ll Document It After Go Live”

There’s always someone arguing documentation can wait until after go live. The logic is hard to fault in a planning meeting. The system isn’t finished. Screens are still changing. Why write procedures against something that’ll look different in 6 weeks. Then go live arrives, the team moves onto the next

Same Road, Different Technology

There’s always someone announcing that AI writing is slop. Usually in a comment, usually with some variation of “you can always tell”. I read a lot of those. What strikes me isn’t the argument, since the argument is mostly aesthetic. It’s how familiar the shape of it is. Every significant

The Requirements Are in the Conversation, Not the Document

Ask most people what a business analyst does and you’ll get an answer about documentation. Writing specs, keeping the traceability matrix current, running things through a change control process. That’s the visible part. The part that actually determines whether a program lands is much less visible, which is sitting with