Building Troubleshooting Instinct in a New Technician

Thursday, 14:05, at Acme. Tom, six weeks on the desk, has a ticket that says "can't get to the shared drive" from a buyer in purchasing. He has been on it for forty minutes. He has restarted her computer, removed and re-added the drive mapping, and checked that she can reach the file server by name. He has run the network troubleshooter twice, and is now reading an article about a setting he has never heard of. Nadia, who has been on the desk nine years, walks past, glances at the screen, and asks the buyer one question over Tom's shoulder: "Did it work yesterday?" "Yes, until I changed my password this morning." Nadia walks on. Tom clears the saved credentials for the share, and the drive opens. He sits for a moment with the particular feeling of a person who has just watched forty minutes of work be replaced by one sentence.

Troubleshooting instinct is the feel for where to look first, and it is not a gift. It is two ordinary things stacked. First is a count of patterns seen, which only time supplies. Second is a habit of asking certain questions before touching anything, which can be taught in an afternoon and practised for a year. Nadia did not know the answer when she asked. She knew which question would narrow the search fastest, and that is the whole of the skill. This article is part of our Training & Developing Technicians series. It is about how a desk grows that habit in a new technician faster than the queue would on its own.

It covers why instinct is a pattern count, the questions that come before the clicks, and cheapest-first, briefly. Next come the hypothesis habit, the what-changed question, and reviewing the path and not the answer. Then come a table of first questions by symptom and what to do when instinct is wrong. A short war story and the troubleshooting debrief card to copy finish the article, in that order.

Instinct Is a Pattern Count

An experienced technician sees a symptom and a short list of causes arrives unbidden. The list arrives because they have seen the symptom many times and remember what it turned out to be. "Can't get to the shared drive, worked yesterday" sits beside "changed password this morning" in Nadia's memory because she has seen the pair forty times. Tom has seen it once, now. There is no way to give him the other thirty-nine except to let him see them. This is the honest limit of any training article: instinct is mostly count, and count is mostly time.

What a desk can do is raise the number of patterns a technician extracts from each ticket, because most tickets teach nothing by default. A technician who fixes a thing, closes the ticket and moves on has added one entry to the count. Another technician fixes it and then spends two minutes asking "what was the shortest path to that, and what question would have got me there?" That technician has added the pattern, the shortcut and the question, and the question is reusable across every category. Three entries for the price of one. Over a year the difference between those two technicians is not talent. It is the two minutes.

The other thing a desk can do is lend the technician its count. The knowledge base, the known-error list and the colleague who narrates are all borrowed patterns. A new technician who reads the fix before they need it has a pattern they did not pay for. The knowledge base as a training tool is the subject of its own article. Here it is enough to say that reading twenty known errors on day one is twenty patterns the queue would otherwise have taken a season to supply. (The queue is generous with lessons and terrible at scheduling them.)

The Questions Before the Clicks

The habit that can be taught is to ask five questions before touching anything, and to ask them in order, because each one cuts the search in half. Start with "What exactly happens, and what did you expect to happen?" Then ask "When did it last work?" and "What changed between then and now?" Next are "Does it happen for anyone else or anywhere else?" and "What have you already tried?" A technician who has those five answers before the first click has usually halved the list of causes four times. That leaves a short list, and short lists are what instinct looks like from the outside.

The first question matters most and is skipped most. "Can't get to the shared drive" is a conclusion, not a symptom. The symptom is what appears on the screen when she tries. It might be an error about credentials, a drive letter with a red cross, a folder that opens and shows nothing, or a spinning cursor that never stops. Each of those is a different fault. "What exactly happens, and what did you expect?" turns the requester's conclusion back into an observation. The second half of the question catches the ticket that is a misunderstanding rather than a fault. The same question is the one that turns a feeling into something measurable, which Turning a Feeling Into a Measurement works through for the hardest case, the vague complaint that something is slow.

Ask the questions in the first reply or the first minute of the call. Write the answers in the ticket before doing anything else, so that the next person to open it has them too. The reflex to be resisted is the one Tom had: the symptom arrives, a plausible fix arrives with it, and the fix is applied before the symptom is understood. The plausible fix is right often enough to be reinforcing and wrong often enough to cost the afternoon. A good trainer catches the reflex by asking "what did she say actually happens?" and watching the technician discover they do not know.

Cheapest-First, Briefly

Once the questions have produced a short list, the order to test it in is cheapest and likeliest first. That order has its own article, The Diagnostic Order, which this one will not redo. The idea in a sentence: check the things that take a minute and are often the cause before the things that take an hour and are rarely the cause, even when the expensive thing is the more interesting one. Nadia's question cost thirty seconds. The reimage Tom was considering would have cost three hours and would not have helped.

Cheapest-first applies beyond hardware, which is where new technicians often stop applying it. For an account problem the cheap checks start with whether the account is locked, and whether the password was changed. Also check whether the user is on the network they think they are on, and whether anyone else has the same problem. For an application fault they are whether it happens for another user on the same machine, and for the same user on another machine. Between them, these separate the person from the computer in two tests. Teach the two-by-two early: same user, different machine; different user, same machine. It is the fastest cut a desk has, and it needs no tools at all.

The place instinct enters cheapest-first is in the word "likeliest", because likelihood is what the pattern count supplies. A new technician can order by cost on day one. Ordering by likelihood takes the count, and the trainer's job is to lend theirs: "on this desk, when a printer stops for one person and not the others, it is the driver on their machine four times in five, so check that before the queue." That sentence is a borrowed pattern with a ranking attached, and the technician will remember it the second time it is right.

The Hypothesis Habit

A hypothesis is a guess at the cause, said aloud or written down, with a prediction attached: "I think it is the saved credentials, and if I am right, clearing them will make the drive open on the next attempt." The habit is to form one before each test, to test only that one, and to say afterwards whether the prediction came true. It sounds pedantic, and it is the single difference between troubleshooting and clicking. A technician who changes five things and then finds the fault working does not know which of the five did it. They cannot write a note anyone can reuse, and have four changes on the machine that nobody asked for.

The hypothesis habit also makes the technician's reasoning visible, which is what lets a trainer correct it. "What do you think it is?" "The network." "What would you see if you were right?" A pause. The pause is the lesson: a hypothesis without a prediction is not a hypothesis, it is a mood, and the technician cannot test a mood. Push for the prediction every time. Within a month the technician will push for it themselves. The trainer will hear them muttering "if that's right, then..." at the screen, which is the sound of instinct being built.

One hypothesis at a time also protects the requester, who is watching a stranger change things on their computer and would like to know why. "I think it is the saved password; I am going to clear it and ask you to try again" is a sentence a requester can follow and agree to. Five silent changes followed by "try it now" is not. The habit that makes the technician better at diagnosis is the same one that makes them trusted at the desk side, and the two reinforce each other.

The What-Changed Question

"What changed?" is the most powerful question in troubleshooting. A thing that worked yesterday and does not work today was changed by something, and finding the something usually finds the fault. The change may be the user's: a new password, a new phone, a laptop taken home for the first time, an update accepted on the way out of the door. It may be the desk's: a permission adjusted, a group changed, a policy pushed. It may be a vendor's: an update nobody asked for. It may be time itself: a certificate expired, a licence lapsed, a password reached the age at which the policy forces a change. The question is cheap, the requester usually knows the answer, and the answer points.

The requester will often say "nothing changed", and the technician's job is to ask it a second way rather than to accept the first answer. "Nothing changed" means nothing the requester noticed. "Did you get a new phone, change a password, take the laptop anywhere, or accept any update since it last worked?" is the same question with the memory prompts attached. It finds the change a surprising amount of the time. (Nobody has ever changed anything. The machine did it. The machine is very busy.) The second asking is not disbelief; it is the technician knowing that memory needs a handle to hold.

The desk's own changes are the ones the technician can look up rather than ask about. A desk that keeps a record of its changes has a what-changed answer for every ticket that arrives the morning after. Which changes deserve a record is the subject of What Needs Review and What Does Not. For the troubleshooter the point is simpler: before blaming the user's machine, check whether the desk did something last night. A technician who learns to look at the change record first will, about once a month, solve a ticket without touching the computer at all.

Reviewing the Path, Not the Answer

The review that builds instinct looks at the route the technician took to the fix, not at whether the fix was right. The fix being right is often luck and the route is always a habit. The trainer and the technician open the closed ticket and ask three questions. They ask what path was taken, what the shortest path available was, and which question, asked earlier, would have joined the two. Tom's path was restart, remap, name check, troubleshooter, article; the shortest path was one question and one click; and the question was "when did it last work?". That review takes two minutes and gives Tom a pattern, a shortcut and a question. The answer alone would have given him none of those.

The review needs the path to have been recorded, which is an argument for working notes that most new technicians have not yet heard. A technician who writes each step into the ticket as they go has a path the review can read. One who writes "fixed, cleared credentials" at the close has a path that exists only in memory and will be remembered as shorter than it was. If you run QuerySolv, the ticket's event history holds every note and reply in order with its time. So the review reads the ticket rather than the memory, and most tools keep something like it. The habit of writing the steps as they happen is laid out in Writing Reproducible Steps, and it is as much a training tool as a documentation one.

Praise the path when it was good, and be specific about what was good about it. "You asked what changed before you touched anything, and that is why it took ten minutes" teaches more than "nice work", because it names the habit the technician should repeat. Correct the path when it was long, and be specific about the question that would have shortened it. Do so without any suggestion that forty minutes was a failing. It was forty minutes of pattern-building, and the review is what turns it into a pattern. The reviewed ticket is worth three unreviewed ones, and the review costs two minutes. There is no better rate on the desk.

First Questions by Symptom

The table below is a starter set of borrowed patterns: for each common symptom, the first question to ask, the cheapest check, and what it usually turns out to be on a small desk. It is a desk's own count written down, and a new technician reads it on day one and adds to it as their own count grows. The "usually" column is not a rule; it is a ranking, and a ranking is what instinct looks like when someone is honest about where it came from. Keep the table in the knowledge base where the trainee can find it, and let the desk argue about the last column, because the argument is itself a transfer of patterns.

Notice that the first question for most rows is the same question wearing different clothes. It separates the person from the machine, or the one from the many, or the now from the yesterday. A technician who sees that the seven rows are really three questions has learned something the table did not say. That is the moment the pattern count starts compounding rather than just growing.

When Instinct Is Wrong

Instinct fails in a specific way: the pattern count says "it is always X" and the technician fixes X without checking, and this time it was Y. The failure belongs to experienced technicians more than new ones, because a new technician has no "always" yet. It is worth warning the trainee about early so that they recognise it when it arrives in year two. The cure is the hypothesis habit, which is cheap insurance: say what you think it is, say what you would see if you were right, and look before you fix. The look costs thirty seconds. Skipping it costs the afternoon about one time in ten, and that one time is the one the requester remembers.

The desk can also tell a technician when their instinct has drifted, from the tickets. A pattern of reopens in one category, or a pattern of fixes applied that did not match the recorded symptom, shows up in the weekly review. It shows up there before it shows up in the technician's self-image. That review, done with care and never as a ranking, is the subject of Feedback and the Ticket Review. Instinct that is never checked against outcomes becomes superstition, and a desk full of confident superstition is slower than a desk full of careful beginners.

A Short War Story: The Reimage at Redbrook Engineering

At Redbrook Engineering, a technician called Kofi, three months on the desk and proud of his pace, took a ticket from a design engineer called Hana. It said her laptop had become "unusably slow since Monday". The desk had reimaged two slow laptops that quarter and both had come back fast. So he booked it in, took it away, and reimaged it that afternoon. Hana lost most of a day while the machine was rebuilt and her applications reinstalled. The next morning it was exactly as slow. The slowness was a mapped drive to a file server the infrastructure team had decommissioned on Sunday. The machine tried to reach it for ninety seconds at every sign-in and every file dialog. The desk's own change record had the decommissioning in it, dated, and "since Monday" had been in the ticket's first line. The cost was Hana's day, Kofi's afternoon, a conversation with the engineering manager about why the fix had not worked, and a reimage nobody needed. Kofi's instinct had said "slow laptop, reimage", and the instinct was built on a count of two. One question, "what changed on Monday?", would have cost a minute and pointed at the change record. The whole thing would have been a drive mapping removed before lunch.

The Troubleshooting Debrief Card

The card below is filled in by the technician in the two minutes after a ticket closes. Use it for every ticket in the first month and for any ticket that took longer than an hour after that. Read it with the trainer once a week. The top half records the questions asked and the hypotheses tested, in order. The bottom half is the review of the path: the shortest route available, the question that would have found it, and the pattern to keep. A stack of cards is a technician's own count, written down. The "pattern to keep" line, copied into the knowledge base when it is new to the desk, is how one technician's afternoon becomes everyone's thirty seconds.

TROUBLESHOOTING DEBRIEF CARD — TWO MINUTES AFTER THE CLOSE
Ticket: ________   Technician: ______________   Date: ________   Time taken: ______

THE FIVE QUESTIONS (answered before the first change?  yes / no)
  What exactly happened, and what was expected: ______________________________
  When it last worked: ______________________________
  What changed since (user / desk / vendor / time): ______________________________
  Who else has it, where else does it happen: ______________________________
  Already tried by the requester: ______________________________

HYPOTHESES, IN THE ORDER TESTED
  1. I thought: ________________  If right I would see: ________________  Result: ____
  2. I thought: ________________  If right I would see: ________________  Result: ____
  3. I thought: ________________  If right I would see: ________________  Result: ____
  Changes made that were NOT the fix and have been reversed: ______________________

THE REVIEW OF THE PATH
  The path I took: ______________________________________________________
  The shortest path available: ___________________________________________
  The question that would have joined them: _______________________________
  Cheapest-first followed?  yes / no    One hypothesis at a time?  yes / no

THE PATTERN TO KEEP
  Symptom: ______________  First question: ______________  Usually: ______________
  New to the desk?  yes / no    If yes, added to the knowledge base on: ________

Read with: ______________  on ________   One line for next time: ______________

Tom filled in his first card for the shared-drive ticket on the Thursday and wrote, under the question that would have joined the paths, "when did it last work, and what changed". Nadia read it on the Friday and added one line: "Ask it before you open anything. Even the ticket." The next Tuesday a ticket arrived from the same department about a different drive. Tom asked the question in his first reply, got "I changed my password yesterday" back in four minutes, and closed it in six. He has the card in the knowledge base now, as a pattern. It is the forty minutes, paid back at a rate he did not expect.

Frequently Asked Questions