How to interview for operating processes without wasting anyone's time

Ask someone how a process works and you get the official version: tidy, sequential, and missing the parts they have stopped noticing. Nobody is hiding anything. Practiced work becomes invisible to the person doing it, and improvised work gets remembered as the standard method.

The way around this is not better rapport. It is asking about specific recent cases instead of about the general shape, and asking the right people in an order that lets each answer check the last.

What to take away

Never ask how it usually works. Ask about the last three, by name and date, and let the pattern emerge from cases rather than from summary.
The person receiving the output knows things the person producing it cannot know, and vice versa. Neither has the whole picture and both think they do.
Write down the exact words people use for stages and states. Where two people use different words for the same thing, or the same word for different things, you have found a real defect.

Ask about the last one, not the usual one

This single substitution does most of the work.

"Walk me through the most recent one you handled" produces detail. The person reconstructs an event rather than describing a category, so the awkward bits come along: the missing attachment, the message they sent to chase something, the bit they did by hand because the system was slow that day.

Those improvisations are usually adaptations to a system that does not fit the work, which is the framing used in the UK Health and Safety Executive's material on managing human failure.

Then do it twice more. Three real cases give the variation you came for. The third usually contradicts something in the first, the most useful moment in the conversation.

Three recent cases are a small, deliberately unrepresentative sample. Being clear about that is the point of thinking in terms of sampling.

If they reach for the general version, bring them back gently by asking for a specific detail: who sent it, what time it arrived, what the first thing they did was. Specifics restart the memory.

Who to ask, and what each can tell you

Who	What they know	What they cannot see
The person doing the work	Exceptions, workarounds, what they check twice	Whether their output causes problems later
The person receiving the output	What arrives incomplete and how often	Why it arrives that way
The requester at the front	How long they waited before anything visible happened	Anything after they handed it over
Whoever covers during holidays	Which parts are undocumented, because they had to ask	The rest of it
The most recent joiner	Which parts are confusing or arbitrary	What used to be worse
Whoever owns the risk behind a control	Why a step exists	Whether the step still catches anything

Two of these are usually skipped and are the most productive. The holiday cover has recently done the job without the tacit knowledge, so they can tell you exactly where the documentation runs out. The newest joiner has not yet normalized the oddities, and that window closes within a couple of months.

Who to interview and why

Who

Person doing the work: Exceptions, workarounds
Person receiving output: What arrives incomplete
Requester at the front: How long they waited
Holiday cover: Undocumented parts
Most recent joiner: Confusing, arbitrary parts
Risk owner: Why a step exists

What they know

Person doing the work: Later output problems
Person receiving output: Why it arrives that way
Requester at the front: Anything after handover
Holiday cover: The rest of it
Most recent joiner: What used to be worse
Risk owner: If it still catches

What they cannot see

Person doing the work
Person receiving output
Requester at the front
Holiday cover
Most recent joiner
Risk owner

Questions that produce something usable

Grouped by what you are trying to find out. You will not need all of them.

Question groups to ask

Exceptionshow many of last ten went as intended
Waitingwhat is sitting on your desk now
Hidden toolswhat is open beside the official system
Mistrustwhat do you check twice
Missing informationwhat do you have to guess
Fragilitywhat breaks if you are away two weeks

To find the exceptions. Of the last ten, how many went exactly as intended? What happened to the others? What is the version that makes you sigh when you see it arrive? When did you last have to ask someone for permission to do something out of the ordinary?

To find the waiting. After you finish your part, what happens to it? When you are stuck, what are you usually stuck on? What is sitting on your desk right now, and what is each item waiting for?

To find the hidden tools. What do you have open while you do this that is not the official system? Is there anything you keep your own record of? What do you copy from where?

To find the mistrust. What do you check twice? What do you not believe when the system tells you? What do you do to protect yourself against something going wrong later?

To find the missing information. What do you have to ask other people for? What should have arrived with the work and did not? What do you have to guess?

To find the fragility. If you were away for two weeks unexpectedly, what would go wrong first? What can only you do? What would somebody covering for you get wrong?

Ask the last group of anyone senior in the work and take the answers seriously. They are the fastest inventory of single points of failure you can get, and they are usually accurate.

Reading the answers

Some answers mean something fairly reliable.

What the answers mean

Answer

It depends: Missing branch
We usually just...: Standard workaround
That never happens: Rare event recalled
You'd have to ask X: Dependency, concentration risk
Long pause on why: Reason gone, not step
Same word, two states: Defect at handoff

What it means

It depends
We usually just...
That never happens
You'd have to ask X
Long pause on why
Same word, two states

"It depends"is an invitation, not an evasion. Ask what it depends on, and you have found the branch that is missing from every description of the process.
"We usually just ..."marks a workaround that has become standard. The word "just" is doing a lot of hiding.
"That never happens"followed a minute later by an example is normal. People classify rare events out of the process and then remember them.
"You'd have to ask X"identifies a dependency. Count how often one name comes up across several conversations; that is your concentration risk, and it is a team management problem before it is a documentation one.
A long pause before an answer about why a step existsusually means the reason is gone rather than the step being pointless. Find out what it catches before you touch it.
Two people using the same word for different statesis a defect you can fix this week, and it explains a surprising share of the rework at that handoff.

Questions that waste the interview

"How does the process work?" Produces the official version. Everything above exists to avoid this.

Wasted questions and replacements

Avoid

How does the process work?: Walk me through the last one
What would improve it?: What would have made last case easier
Is the documentation accurate?: When did you last open it
Why do you do it that way?: What if done the other way
Anything answerable with yes: Open, specific questions

Ask instead

How does the process work?
What would improve it?
Is the documentation accurate?
Why do you do it that way?
Anything answerable with yes

"What would improve it?" Sometimes useful, usually gets either the answer they have been proposing for two years or a request for more staff. Ask what would have made the last difficult case easier, which is answerable.

"Is the documentation accurate?" Nobody says no about a document they may have written. Ask when they last opened it, and watch whether they can find it.

"Why do you do it that way?" Sounds like a challenge whatever your tone. Ask what would happen if it were done the other way, which gets the same information without a defense attached.

Anything answerable with yes. You will get yes.

After the conversations

Three things to do while it is fresh.

Three things to do after

Write down the exact words people used
Check one claim against a timestamp or folder
Show the picture back before taking it anywhere

Write down the words people used, exactly, particularly the names of stages and states. Your summary will smooth over the inconsistency that is worth finding.

Check one thing you were told against something that is not an opinion: a timestamp, a folder, a queue, a sample of recent items. Not because people are unreliable, but because the parts they are most confident about are the parts they have stopped examining.

Then show the picture to the people who gave it to you, awkward bits included, before you take it anywhere else. If they first see their process described in a document sent upward, with workarounds listed, they will rightly conclude this. Talking to you was a mistake.

This is also when anything you plan to change becomes a change management matter, not an analytical one.

Scope the exercise before you start. Set the boundary and the level you are working at, per operating processes framework.

For what to do with findings, the four fields that describe any process are in operating processes.

If answers point to wrong output, not slow output, ask different questions. Those belong with quality management.

Common questions

How long should one of these conversations take?

Forty minutes with one person, covering three real cases, is usually enough and is about the limit of anyone's patience. Two shorter conversations a week apart beat one long one, because the first will have made them notice things.

Should I record it?

Notes are usually better. Recording changes what people say about workarounds and about colleagues, which is precisely the material you need. If you do record, ask, and accept a no without negotiating.

People keep telling me the problem is another team. What do I do with that?

Take it as a description of where the handoff hurts, not as a finding about the other team. Then ask the same questions there. The reliable result is that both sides are describing the same undefined word or missing field from opposite ends, and neither has heard the other's version.