Asking Good Questions and Gathering Information

Facts before theories

The first step of a structured troubleshooting method is to identify the problem. It sounds obvious, and it is the step most often skipped: a user says "Outlook is broken", and within seconds we are already thinking about profiles and caches. But "Outlook is broken" can mean a crash at start-up, one missing shared calendar, a full mailbox, or a forgotten password.

Five minutes of good questions usually saves an hour of fixing the wrong thing. They also show the user that you take the problem seriously — and the answers go straight into the ticket, so nobody has to ask again.

Questioning users

Open and closed questions

An open question invites a description in the other person's own words: "What happens when you try to log in?", "Can you walk me through what you did?". It gives you information you did not know to ask for.

A closed question has a short, fixed answer — yes or no, a number, a choice: "Does it happen on your colleague's PC too?", "Which office are you in?". It confirms or rules out something specific.

You need both, in that order. Open questions first, to understand the problem without steering the answer. Closed questions next, to narrow down. And at the end, a summary in your own words that the user can correct: "So since this morning, the invoice export gives an error for every region except North — is that right?" That last step catches misunderstandings while they are still cheap.

Questions that work

How you ask matters as much as what you ask. Compare two openings of the same call to the Kestrel Energy service desk:

Desk: Did you change something on your PC?
User: No.
Desk: Did you restart it?
User: Yes, of course.
Desk: And you're sure you typed the password right?
User: I've been typing it for three years...

Desk: What happens when you try to open the portal?
User: I get the login page, I log in, and then it just goes
      back to the login page.
Desk: Has it worked before on this PC?
User: Yes, until yesterday.
Desk: Has anything been different since yesterday - a
      notification, an update, a new device?
User: Oh - IT replaced my laptop yesterday afternoon.
Desk: That helps. Could you share your screen and show me?

The second call finds the key fact — a new laptop — in three questions, because the user is invited to tell the story instead of defending themselves. Some habits behind it:

• Ask about the situation, not the person. "Has anything been different since…" gets more honest answers than "Did you change something?". People rarely know what counts as a change, and nobody likes to feel accused.
• Ask them to show you. Screen sharing or standing next to someone shows the clicks, the warning they always ignore, and the error text exactly as it appears.
• Use their words, then check yours. If the user says "the system", ask which screen or application they mean. Avoid jargon; explain a term if you need it. More on this on communicating with users and customers.
• Ask one question at a time, and let silences be. People often add the important detail after a pause.

The first questions for any problem

Whatever the technology, the same facts come back. Many teams keep them as a checklist in the ticket template:

WHAT     What exactly happens? Exact error text or screenshot.
         What did you expect to happen?
WHEN     Since when? Always, sometimes, at certain times?
WHO      Only you, your team, your location, everyone?
WHERE    Which device, application, network (office, home, VPN)?
CHANGE   Has anything been different since it started?
         (updates, new device, moved desk, new password)
REPEAT   Can you make it happen again? Which steps?
TRIED    What have you already tried, and what happened?
IMPACT   What can you not do now? Is there a deadline?
         Is there a workaround you can use for now?

Two of these deserve special attention. Scope (who and where) is the fastest filter there is: "only Utrecht" points at something local, "only on VPN" at the network path, "only this user" at the account or device. And what changed is the single most productive question in IT, because systems that worked yesterday usually fail today for a reason that happened in between. Check the change schedule too: users often do not know about the change that affected them.

The impact answer feeds the ticket's priority (see impact, urgency and priority).

Reproducing the problem

Problem reproduction means finding the steps and conditions that make the problem happen again, preferably on demand. A problem you can reproduce is half solved: you can watch it happen, test theories against it, and prove that your fix works by running the same steps again.

Ways to reproduce, from least to most effort:

• Let the user show it while you watch.
• Try the same steps yourself, with a test account or on a similar device.
• Rebuild the situation in a test environment: same version, same settings, same data (anonymized where personal data is involved).

If you can reproduce it with the user's account but not with yours, the difference is your next clue: permissions, profile, group membership, settings. If it happens on the user's laptop but not on an identical one, compare the two.

Intermittent problems

Some problems come and go: "the VPN drops sometimes", "the report is slow now and then". You cannot reproduce them on demand, so you collect occurrences instead. Ask the user to note the exact time each time it happens (and what they were doing), then compare those times with logs and monitoring. Three exact timestamps are worth more than "it happens a lot". Patterns appear: always around 09:00, always on Wi-Fi, always after a laptop has slept.

Collecting evidence

Memory is unreliable — the user's and yours. Capture facts while they are fresh, in the ticket:

• The exact error text, copied as text where possible. A screenshot is good; text is searchable. "It gives an error" is not evidence.
• Timestamps with a time zone, so you can find the moment in the logs. Logs often use Coordinated Universal Time (UTC) while the user speaks in local time; see log correlation.
• Versions and identifiers: application version, operating system build, device name, user name, IP address.
• What you tried and what it showed — including the tests that did not find anything. A ruled-out cause is a result.

Asking colleagues and communities for help

Sooner or later you are the one with the question. How you ask decides how quickly and how well people can help.

Before you ask

Eric S. Raymond and Rick Moen's well-known essay "How To Ask Questions The Smart Way" (last revised in 2014) gives a list of things to do before asking: search the forum archives, search the Web, read the manual, read a FAQ, try inspection or experimentation, ask a skilled friend, and if you are a programmer, read the source code. Then, when you ask, show that you have done these things. The essay's tone is blunt and at times rude — it was written for volunteer open-source communities — but the checklist is sound. Inside your own team the bar is lower: a quick question to a colleague is fine, as long as you bring what you already know.

The XY problem

The XY problem is, in the words of xyproblem.info, "asking about your attempted solution rather than your actual problem". You want to do X, you think Y will get you there, Y does not work, and you ask about Y. The helpers solve Y — and it turns out Y was the wrong road to X all along.

How do I give the billing service account local admin rights
on the report server? It keeps saying access denied.

The nightly billing job has to write its CSV export to
D:\exports on the report server (goal). It fails with
"Access denied" since the server was rebuilt on Monday.
I was going to give the service account local admin rights -
is that the right fix, or is there a better way?

The first message invites an answer that works and creates a security hole. The second lets a colleague say: "Do not make it admin — just give it write permission on that one folder, it was lost in the rebuild." The advice of xyproblem.info: "Always include information about a broader picture along with any attempted solution."

A minimal reproducible example

For problems with code, scripts or configuration, the best gift you can give a helper is a minimal reproducible example: the smallest complete piece of code or configuration that still shows the problem. Stack Overflow's help page describes three properties:

• Minimal: "Use as little code as possible that still produces the same problem".
• Complete: "Provide all parts someone else needs to reproduce your problem in the question itself".
• Reproducible: "Test the code you're about to provide to make sure it reproduces the problem".

Suppose a 300-line import script crashes on a meter-reading file that a user exported from their spreadsheet. Instead of sending the whole script and the whole file (with customer data), cut it down until only the problem is left:

import csv
import io

# Three lines from the meter export, exactly as saved by the user's spreadsheet
export = "meter_id;reading\nKE-1001;4521\nKE-1002;3980\n"

rows = list(csv.DictReader(io.StringIO(export)))
print(list(rows[0].keys()))
print(rows[0]["reading"])

['meter_id;reading']
KeyError: 'reading'

Nine lines, no customer data, and anyone can run them. Often, making the example is enough to see the answer yourself: the file uses semicolons, which is common for CSV files saved by spreadsheet software set to Dutch regional settings (where the comma is the decimal separator), and the script expects commas. Stack Overflow's page suggests two ways to get there: start from scratch and add only what is needed, or divide and conquer — remove half and check whether the problem is still there, which is half-splitting applied to your own code.

A good help request

Put together, a request for help in a team channel or forum looks like this:

Goal:      what I am trying to achieve (X)
Problem:   what happens instead - exact error text
Since:     when it started; what changed around then
Tried:     what I tested and what each test showed
Example:   minimal reproducible example, or exact steps
Context:   versions, environment (test or production)
Question:  the specific thing I need help with

And when you get an answer: say whether it worked, and if you solved it another way, post the solution. The next person with the same problem — possibly you, next year — will find it.

Explaining it out loud

Rubber duck debugging is explaining a problem step by step, out loud, to someone or something that does not need to answer — classically, a rubber duck on your desk. The name comes from a story in Andrew Hunt and David Thomas's book The Pragmatic Programmer (1999), about a programmer who explained his code to a duck. It works because explaining forces you to state every assumption, and halfway through you notice the one that is wrong. See also the debugging page.

It works for more than code. Writing a help request with the template above is rubber-ducking in writing: surprisingly often, by the time you reach "Tried:", you know what to try next and never send the message. AI chat assistants can play a similar role, with the rules on using AI at work — especially about what you must never paste into them.