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

Why UX/UI and Business Analysis Belong in the Same Room

There’s a pattern I’ve seen on more than a few platform rollouts. The business analyst writes the requirements. The designer picks them up afterwards, then makes them look good. Development builds it, testing signs it off, the thing goes live. Six weeks later the support tickets start. Not because the

Why People Skills Matter More Than Technique for a Business Analyst

You can learn the technical side of business analysis in about 6 months. Requirements templates, process notation, user stories, traceability matrices, gap analysis. It’s all learnable, all documented, all fairly consistent from one organisation to the next. What takes years is the other part. Getting a room full of people

Digital Transformation Projects Run on People, Not Plans

I’ve worked on programs with excellent methodology that went badly. I’ve worked on messy ones that landed well. The difference was never the framework. It was who was in the room, how they got on, whether anyone was willing to say the difficult thing out loud. That’s not a soft