Asking Effective Questions About Work

Interviews are one of the most common ways to learn how work gets done. You ask a person what they do, in what order, and who they hand it to. The answers are useful, but they have a limit. People tend to describe their work as it is supposed to happen, not as it actually happens. Before you can study a process carefully, you need to notice that the account you were given and the process itself are not the same thing.

Consider a simple case. A colleague explains how incoming requests are handled: a request is logged, reviewed, approved, and the result is sent back. The explanation is clear and confident. It may even be accurate in outline. Yet the explanation has been tidied in memory, and it leaves out the pauses, the phone calls, and the small fixes that happen between those steps. This lesson is about that difference and why it matters.

A described workflow usually appears in a manual, a process document, or a confident verbal explanation. It is the clean, intended form of the work. People produce it when they describe a routine they perform every day, and it is shaped by memory and by how the work is meant to run. An actual workflow is the version that unfolds when the work is carried out. It includes workarounds, waiting, favors between colleagues, and exceptions that rarely come up when someone describes a process from memory.

The two versions are often close enough that the difference is easy to overlook. Both usually share a starting point and an ending point. A request arrives and a result is eventually sent. The divergence tends to live in the middle, in three kinds of places: where a step is slower than expected, where someone checks with a colleague before proceeding, and where a case arrives that the official account never considered.

Work through a short scenario to see this. A team receives requests that sometimes arrive without enough detail to approve. The documented process says: log the request, the reviewer approves it, the result is sent. In practice, the reviewer first checks whether the information is complete. If it is not, the reviewer emails the requester, waits for a reply, and then approves. Once approved, the reviewer copies the result into a spreadsheet the team uses for tracking, because the tracker does not show it to the requester. The flowchart below traces both paths from the same starting point.

Read the diagram from the decision point. The described path goes straight from a complete request to approval. The actual path leaves at the decision when information is missing. The email, the waiting, and the spreadsheet copy never appear in the described account, yet they are where the team is spending its effort. The shared start and end points still match, which is exactly why the divergence is easy to miss.

Interviews have a natural ceiling. People describe work in its clean, intended form, so a interview alone will tend to show the tidy version. The gap between the described and actual versions is useful for exactly that reason. It marks the conditions the work must really handle: slow steps, consultations, exceptions, and workarounds.

The comparison shows the difference in steps, order, and people. The described account has three steps and one person. The actual account has six steps and involves the requester as well. Each added step is a place where the work has to handle something the description did not mention.

Studying the gap is a method. Begin by confirming the shared steps, the parts where both accounts agree. Once those are established, trace where waits, corrections, exceptions, and workarounds appear. Those four categories are the places where the actual workflow leaves the described one.