Good troubleshooters aren't people who've memorized more. They're people who follow a method instead of guessing. Guessing feels faster and is almost always slower, because you change five things, one of them works, and you never learn which.
Here's the method, then the specific first moves for the failures you'll see most.
The first question is never "what's broken." It's "how big is this?"
Scope tells you where to look before you've spent a minute looking. If it's everyone, stop poking at the user's laptop — the problem is upstream.
Systems that worked yesterday and don't today almost always changed. An update, a password expiry, a certificate, a full disk, a new firewall rule, someone "just plugged something in." Ask the user what changed, then don't fully trust the answer — people genuinely forget. Check update and change logs yourself.
This is the actual skill. Don't work from one end; cut the chain in the middle and find out which half is broken. Each test should eliminate roughly half the possibilities.
Change one variable, test, then put it back if it didn't help. Changing three things at once means you can't tell which fixed it, can't document it, and can't fix it faster next time. This is the discipline that separates people who solve problems from people who occasionally stumble into solutions.
Thirty seconds in a ticket saves an hour the next time — for you or whoever gets it next. It's also what turns three years of experience into three years of *knowledge* instead of the same year three times.
Check scope first. Then: does the machine have a real IP, or a 169.254.x.x address? (That means DHCP failed.) Can it ping the gateway? Can it resolve a name? Can it reach an IP directly? The name-vs-IP split is your halving test — it separates DNS from everything else.
Open the task manager or top and find what's consuming CPU, memory, or disk. Then check free disk space — a nearly full drive makes everything crawl and produces symptoms that look like ten unrelated problems. Reboot only after you've looked, or you destroy the evidence.
Scope: one person or many? Wrong password, locked account, expired password, or expired certificate? Check whether it fails on a different machine — that splits "user/account problem" from "this device problem" in one test. And check the clock: badly wrong time breaks Kerberos and certificate validation in ways that look mysterious.
Genuinely the most reported and least glamorous. Is it on and does it have paper and toner? Can another user print? Is the queue jammed with a stuck job — clear it. Can you reach the printer's IP? Most "printer problems" are a stuck queue or a printer that changed IP because it was on DHCP instead of a reservation.
Try their account on another machine, and another account on their machine. Those two tests tell you whether it follows the user or follows the device — which is the whole answer.
The IT Pro's Troubleshooting Flowchart Pack — decision trees for the most common failures, printable, so the method is in front of you when it's busy. Instant download.
Get the pack — $7 →Find out how big it is, ask what changed, cut the problem in half, change one thing, and write down what worked. That method handles problems you've never seen before — which is most of them.
Useful alongside: ports and protocols for "what's actually listening," the Linux commands sheet, and interview questions — where "walk me through troubleshooting X" is the most-asked question there is.