Read summarized version with
To interview a subject matter expert, run six stages in a fixed order: Frame, Walk, Probe, Verify, Cover, Write, and only move down a rung once the current one is satisfied. The interview is finished when you can write the document, not when you run out of questions.
I’m Yuval, founder of Glitter AI. I’m a solo founder, I bootstrapped this company with $0 raised, and I wrote the first line of code in September 2023. Which means most of the processes that keep my business alive are run by someone who isn’t me, and the only way I get them written down is by asking.
The mistake I made for years was treating the interview as a conversation. You book thirty minutes, say “walk me through it,” take notes, and afterwards discover you have anecdotes instead of a procedure. Missing the thing that goes wrong in week two, and who to call when it does.
A ladder fixes that. Each rung has a job and a done when condition, and the condition is the whole point: it tells you whether you’re allowed to move on. That is also why a fixed sequence beats a free-form chat. In research and in hiring, structured interviews ask the same questions in the same order precisely so the answers can be compared and aggregated with confidence. The same discipline works when the output is an SOP instead of a hiring decision.
Teach your co-workers or customers how to get stuff done – in seconds.
Before the interview: what to read and what to book
Two things happen before you ask anything.
Read what already exists. Old SOPs, the half-finished wiki page, the Slack thread where someone explained the tricky part, an existing recording. Every minute you spend here is a question you don’t have to spend in the room. There is no faster way to lose an expert’s goodwill than asking them to repeat something they already wrote down.
Book the right amount of time. Thirty minutes for one process. Not ninety. A ninety-minute booking tells the expert this is a project, and projects get postponed. Thirty minutes gets accepted, and honestly, thirty focused minutes is plenty for one procedure. As long as you run the ladder and don’t just chat.
Then promise them the artifact. “I’ll send you the written version tomorrow, you tell me what I got wrong.” That one sentence flips things. They’re not being interrogated anymore. They’re grading your homework, and experts love grading homework.
One more piece of preparation: decide who the document is for. A procedure written for a new hire and one written for the expert’s own backup need different levels of detail, and every question you ask should be pitched at that reader. If you want a shared definition of the role you’re about to interview, our glossary entry on the subject matter expert is the short version.
How to interview a subject matter expert: the six-step ladder
Here are the six rungs. Run them in order, one question at a time, and check the done-when condition before you climb down.
Step 1. Frame: get the trigger, the end state, and the stages in one minute
Open with this, more or less word for word:
“Before we go deep, walk me through it start to finish in a minute. What kicks it off, and how do you know you’re done?”
You are not collecting detail yet. You’re collecting the shape: what triggers the process, what the finished state looks like, and roughly how many stages sit in between. Every later question fills in a shape you already hold. That’s where the time savings come from.
Resist the urge to interrupt with detail questions here. If the expert says “then I reconcile the accounts,” write “reconcile” and keep going. You’ll come back to it.
Done when: you know the trigger, the end state, and the list of stages.
Step 2. Walk: one stage at a time, with the confirmation that it worked
Now go back to stage one and slow down:
“Take the first stage. What do you open, what do you click, what do you type, and what do you see when it worked?”
People skip that last clause. It’s the most valuable part of the rung. “What do you see when it worked” gives you the definition of done for each stage, which is what a reader needs in order to know whether to continue or stop and ask for help.
Take one stage at a time. Finish it, paraphrase it back in the expert’s own words, and only then move to the next one. If you get three stages ahead of your own notes, you’ve lost the thread and you’ll be writing fiction later.
Done when: every stage has its actions and its visible confirmation.
Step 3. Probe: decision points, preconditions, exceptions, ownership
Most people never get here. They burned the clock chatting in step one, which is a shame, because this rung is where the good stuff is.
Four questions, asked against each stage:
- “Where do you have to choose between two ways of doing this?”
- “What has to be true before you can start?”
- “What goes wrong most often here, and what do you do when it does?”
- “Who owns this part, and who do you go to when it breaks?”
These pull out the tacit layer: the judgment calls, the preconditions nobody states, the failure modes, the handoffs. Everything a recording of the screen can capture is already in the Walk. Everything a recording cannot capture is in here.
Watch for “it depends.” It may be the most useful phrase an expert says all session, and it’s never the end of an answer. “Depends on what?” gets you the decision rule. Keep pulling until the condition is something a reader could actually check.
Done when: each stage has been probed at least once, and every “it depends” has been resolved into a rule.
Teach your co-workers or customers how to get stuff done – in seconds.
Step 4. Verify: the read-back, and why corrections here are cheap
Stop asking. Summarize the entire process back:
“So the way I have it: first this, then this, and if that happens you do this instead. Did I get that right?”
Two or three minutes, out loud, while the expert is still in the room.
Here’s my own example. Earlier this year I sat down with the bookkeeper who runs Glitter’s month-end close, a process I have literally never performed myself. Fifteen minutes of questions, and I thought I had it. Then I read it back, and about forty seconds in they said “no, that comes after.” I had two stages in the wrong order, confidently, in my own notes.
That correction cost four seconds. Caught after writing, it would have cost a rewrite. Never caught, the next person to run the close hits the wall and quietly decides the document is useless. That’s how documentation dies, usually.
Done when: the expert confirms the read-back.
Step 5. Cover: fill only the gaps the document still has
Now, silently, check what you have against what the finished document needs. Purpose, scope, steps, the FAQ, a glossary of terms, ownership, whatever your template demands.
Then ask only about the gaps. Usually there are one or two:
“Last thing: is there a term in here that a new person wouldn’t know?”
What you must not do is read your template’s section names out loud. Asking a warehouse lead “what are some FAQs for this process?” gets you a blank stare. Asking “what does a new person get wrong in their first week?” gets you the FAQ. The template tells you what you need. It never becomes the question list.
You’ll do most of this rung in your head. The FAQ comes from the mistakes and “what if” answers you collected in Probe, the roles come from the ownership questions, and the glossary comes from the jargon the expert used without noticing.
Done when: every section of the document can be written.
Step 6. Write: turning the transcript into the procedure
Say it out loud so the expert knows the session is over: “I have what I need, I’m writing this up.”
Write it the same day. You probably won’t forget the words. You will forget which parts you were unsure about. Writing is also the only reliable test of whether the interview worked. If you can’t write a step, you didn’t get an answer, and you now know exactly what your follow-up message asks for.
Write in the reader’s order, not the order you heard it. Experts narrate by association, and the transcript is going to jump around. Your job is to straighten it. The other job is restraint: what the expert did not say does not go in the document. If there’s a gap you couldn’t fill, note it in a comment or a message back to them, not as an invented step.
Done when: the expert reads the draft and either keeps it or reopens a topic.
Seven rules a good interviewer never breaks
The ladder gives you structure. The habits below are what make it hold up.
-
One question at a time. Follow-ups on the same point can come in the same breath. A new topic never does. Stacked questions get you an answer to whichever one the expert liked best, and you’ll never notice the other one went missing.
-
Concrete over abstract. “Which button do you click?” beats “how do you submit it?” Ask for the real name of the control and the real value that goes in the field. Abstractions are where procedures go to become useless.
-
Paraphrase before moving on. Every stage gets read back in the expert’s own terms before you climb to the next one. It costs ten seconds and catches the misunderstanding while it’s still free.
-
Never invent. If they didn’t say it, it isn’t in the SOP. The temptation is strongest at the end, when one small gap stands between you and a finished document. Mark the gap instead.
-
Let the expert skip or jump. If they say “the next two stages are obvious, let me tell you about the annoying one,” follow them. You’re running a ladder, not reading a script. You can always come back for the skipped part in Cover.
-
Read what already exists first. Then ask only about what it doesn’t say. This is the difference between an expert who takes your next meeting and one who stops replying.
-
Know when to stop. Enough is when the document can be written, not when your question list is exhausted. Ten more minutes of questions you don’t need is how you lose access to an expert for the next process.
How to tell the interview is finished
There’s a simple test, and it isn’t the clock.
Ask yourself whether you could sit down right now and write every section of the document without guessing. Not write it well. Just write it without inventing anything.
If yes, you’re done. Stop, thank them, and go write.
If no, name the specific thing you’re missing and ask that one question. “I still don’t know who approves it” is a real question. “Anything else I should know?” is not, and it almost always gets you “no, I think that’s it” from an expert who really does believe it.
The other honest signal: you’ve stopped being surprised. In a good interview the first ten minutes are full of “huh, I didn’t know that.” When three answers in a row are ones you could have predicted, the seam has run out for today.
A question bank you can steal
Print this, or paste it into the notes doc you’ll have open anyway.
Frame
- Walk me through it start to finish in a minute.
- What kicks this off? A date, a request, an alert, someone asking?
- How do you know when you’re done?
- Roughly how many stages are there?
Walk
- Take the first stage. What do you open?
- What exactly do you click, and what do you type?
- What do you see when that worked?
- What does it look like when it didn’t work?
Probe
- Where do you have to choose between two ways of doing this?
- What has to be true before you can start this stage?
- What goes wrong most often here?
- What do you do when that happens?
- Who owns this part? Who do you escalate to?
- What would a new person get wrong in their first week?
- Has this process changed recently? What did it used to be?
- What do you check that nobody told you to check?
Verify
- So the way I have it, … Did I get that right?
- Is that the correct order?
- Which of those steps could be skipped in a rush, and which absolutely can’t?
Cover
- Is there a term in here a new person wouldn’t know?
- Who reads the output of this, and what do they do with it?
- Is there anything about this you’d only tell someone in person?
That last question is the one I’d keep if I could only keep one. It gives people permission to say the unwritten thing, and the unwritten thing is usually the reason the process exists in its current shape.
After the answers, you still have to make the document
Getting the answers is the hard half. But only half. You still have to produce something a person can follow with their hands on a keyboard, which usually means screenshots, in order, with the right thing circled.
That’s the half I built Glitter for. You record your screen on web, desktop or mobile while you narrate, and the AI transcribes and structures the narration, drops the filler words, and gives you a step-by-step guide with annotated screenshots you can edit, reorder, and export to PDF, HTML, Markdown or MP4. If a video of the process already exists, you can upload it and get a guide from that instead.
The pairing that works for me: the interview gives you the reasons, the recording gives you the steps. If the expert will run the process once while you record, ask them to talk through it as they go, then write the interview material around it.
Teach your co-workers or customers how to get stuff done – in seconds.
And run the ladder before you need it. The worst time to learn how to interview an expert is the week they hand in their notice, which is why capturing knowledge from retiring and departing employees is mostly an exercise in having started earlier. If your organization already pairs people up, the same six rungs turn a mentorship relationship into real knowledge transfer instead of a standing coffee. And once you have the answers written down, the SOP best practices that make a document people actually follow are a separate craft worth an hour of your time.
Six rungs. One question at a time. Stop when you can write it.
Frequently Asked Questions
How do you interview a subject matter expert?
Run six stages in order: Frame the process end to end in one minute, Walk through each stage with its actions and confirmation, Probe for decisions, preconditions, exceptions and ownership, Verify with a read-back, Cover any remaining gaps, then Write. Only move to the next stage once the current one is satisfied.
What questions should you ask a subject matter expert?
Start with what kicks the process off and how they know they are done. Then for each stage ask what they open, click and type, and what they see when it worked. Then ask where they have to choose between two options, what has to be true before starting, what goes wrong most often, and who owns each part.
How long should an SME interview last?
Book thirty minutes for a single process. That is long enough to run all six stages if you stay disciplined, and short enough that busy experts accept the invitation. Complex processes usually take one interview to get a draft and a shorter second pass after the expert has read it.
What is the first question to ask in an SME interview?
Ask them to walk you through the whole process in about a minute, including what kicks it off and how they know they are done. It gives you the trigger, the end state and the rough list of stages, so every question after that fills in a shape you already hold.
How do you get an expert to explain why, not just what?
Ask about choices, preconditions and failures rather than asking why directly. Questions like where do you have to choose between two ways, what has to be true before you start, and what goes wrong most often surface reasoning that a why question usually gets answered with because that is how we do it.
Should you record an SME interview?
Recording is useful if the expert consents, because it frees you to listen instead of transcribing. It does not replace the read-back. Summarizing the process out loud while the expert is still in the room is what catches wrong sequences and missing steps, and a recording cannot do that for you.
What do you do when an expert gives vague answers?
Get concrete. Ask for the name of the button, the value they type, and the confirmation they see. When they say it depends, ask depends on what, and keep going until the condition is something a reader could check for themselves. Vagueness is almost always a sign the question was too abstract.
How many interviews does it take to document one process?
Usually two. The first gets you enough to write a draft, and the second, after the expert reviews that draft, surfaces the exceptions and details they forgot to mention. A simple process with a clear trigger and few decision points can be done in one.
How do you interview an expert who is about to leave the company?
Prioritize by risk rather than trying to capture everything. Pick the processes only they can run, book several short sessions instead of one long one, and run the same six stages each time so each session produces a complete procedure rather than scattered notes.
What is the difference between an SME interview and a user interview?
A user interview explores needs, problems and behavior to inform what you should build. An SME interview elicits a procedure that already exists in someone's head so it can be written down. One is open-ended discovery, the other is structured extraction with a document as the deliverable.
