Documentation work depends, more than most writing, on conversations with people who have no time for them. The engineer who knows how a particular feature actually works. The product manager who knows what the feature is supposed to do. The support agent who knows what users actually struggle with. These are the subject-matter experts — SMEs, in industry shorthand — whose knowledge the writer needs in order to produce documentation that is correct, complete, and useful.
They are also, almost without exception, busier than the writer is. The engineer has a sprint to deliver. The product manager has a roadmap to defend. The support agent is on a ticket queue that never gets to zero. The half-hour meeting the writer needs is the half-hour the SME does not have. The two-week back-and-forth the writer would prefer is, from the SME’s side, a series of interruptions in already overloaded weeks.
This is not a problem that can be solved by demanding more of the SME’s time. It is a problem the writer has to work around, with techniques that get more out of the limited time available. The writers who do this well produce better documentation faster. The writers who do not, struggle perpetually with stalled drafts, missing information, and SMEs who stop responding to their emails.
Respect the SME’s time before you ask for any of it
The first move is to do the work the writer can do alone, before asking the SME for anything. SMEs notice when a writer has clearly prepared, and they notice when a writer has not. A writer who arrives at the conversation having read the existing documentation, tried the feature in question, looked at any related material, and prepared specific questions is a writer the SME will give time to. A writer who arrives expecting the SME to start from the beginning is a writer the SME will quietly avoid.
The preparation work includes the obvious: read what already exists. It also includes the less obvious: try the feature yourself. A writer who has used the feature once, even badly, asks better questions than a writer who has only read about it. The hands-on experience produces specific questions that abstract reading does not.
The preparation work also includes formulating questions in writing, in advance, in a form the SME can react to. Open-ended questions — “tell me how this works” — produce open-ended answers and consume open-ended amounts of time. Specific questions — “when a user with the Editor role attempts X, does the system do Y or Z?” — produce specific answers in much less time.
Ask in the format that costs the SME least
Different SMEs prefer different ways of being asked. The writer who pays attention to this gets better results from less of the SME’s time.
Some SMEs respond best to short written questions in chat or email — they can answer in two minutes between meetings, sometimes from their phone. The writer gets the answer the same day. For these SMEs, a one-question message gets a quick response, and the writer can ask another question the next day, building up the information over time without ever requesting a meeting.
Other SMEs find written questions cumbersome and would much rather have a quick call. For them, a fifteen-minute conversation is worth more than ten emails. The writer should respect this preference and ask for the short call rather than the email exchange.
A small minority of SMEs prefer longer scheduled meetings, where they can go deep on a topic. These are usually the SMEs with the highest seniority or the most ownership over the area being documented. For them, the writer should batch questions and use the meeting time well.
None of these preferences is wrong. The mistake is to apply the same format to every SME. The writer who has learned which SME prefers which mode of contact gets meaningfully more information per hour of their counterpart’s time.
Make the conversation easy for the SME to enter
When a meeting or call is the right format, the writer should arrive at it ready to lead. Not in a controlling way, but in a way that makes the SME’s role easy.
The writer should have a short list of questions, sequenced. The SME should be able to answer them without having to remember what they were supposed to be talking about, work out what level of detail is needed, or guess at the writer’s underlying question. The list, ideally, is shared in advance, so the SME knows what is coming and can think briefly about each item before the call.
The writer should be taking notes themselves, not asking the SME to write things down. The SME’s job is to know things. The writer’s job is to capture what the SME knows in a form that can become documentation.
The writer should also have a draft, where possible. A draft to react to is dramatically faster for an SME to work with than a blank conversation. “Here is what I think this feature does — please tell me what I have wrong” produces specific corrections quickly. “Tell me how this feature works” produces an open-ended conversation that takes much longer to converge on the same level of accuracy.
The follow-up that protects the relationship
After every SME conversation, two things should happen quickly. The writer should send a written summary of what they understood — the key points, the decisions, anything that was unclear — and the SME should be able to confirm or correct it in a single short response. This protects against misunderstandings, gives the SME a chance to add things they remembered later, and produces a written record the writer can refer back to without needing to ask again.
The other thing is appreciation. Not effusive thanks — most SMEs find that uncomfortable — but a brief acknowledgement that the writer knows the SME is busy and is grateful for the time. A one-line thanks in the follow-up email is enough. The cumulative effect, over many interactions, is an SME who responds to the writer’s future requests faster than they would otherwise.
Batching, not interrupting
The single biggest mistake a writer can make with SMEs is to ask questions one at a time, as they arise. Every question is a small interruption. Even when each individual interruption is brief, the cumulative cost — across days of drafting — is significant. The SME experiences the writer as a constant low-level noise.
Batching is the discipline of saving questions until there are several to ask at once. A single message with five questions is cheaper for the SME to answer than five separate messages with one question each. A single meeting that covers all the open items is cheaper than five short check-ins.
The cost of batching, for the writer, is that the drafting cannot be linear. The writer has to be willing to push past questions, leave placeholders, and come back to them once the SME has responded to the batch. This is uncomfortable for some writers, who like to write in order. The discomfort is real. So is the saved SME time, which is what allows the relationship to keep working.
What to do when the SME goes silent
Sometimes, despite the writer doing everything right, the SME stops responding. A meeting is cancelled and not rescheduled. Emails go unanswered. The writer is left with gaps the SME alone can fill.
The first move, in this situation, is not to push harder on the same SME. It is to find another way to get the information. Other engineers in the same team. Support tickets that might illustrate the question. Code or design documents that might answer it. The writer who exhausts the alternatives before escalating preserves the relationship with the busy SME.
The escalation, when it has to happen, should go through the SME’s manager and should be framed as a project risk rather than a personal complaint. The manager can either intervene to make the time available or accept that the documentation will be delayed.
The short version
Documentation depends on SMEs whose time is the scarcest resource in the project. Writers who treat the SME’s time as expensive get better results faster. The techniques are not exotic: prepare thoroughly before asking for any time, ask in the format that costs the SME least, lead the conversation when one happens, follow up with a written summary, batch questions rather than interrupting one at a time, and find alternative sources when the SME is genuinely unavailable. The writers who do this well end up with SMEs who actually look forward to working with them. The writers who do not, end up writing documentation around the gaps where the SME stopped responding.
