Tricks For Technical Troubleshooting
Updated: Nov 20, 2019
How to identify, diagnose, and repair hardware, software and wetware.
Image credit: Pixabay
Jason Maxham's "The Art Of Troubleshooting" is the most comprehensive text on troubleshooting, I've read over the last 40 years.
Jason's recipes provides a roadmap for mechanical, electrical plumbing, HVAC and stakeholders. time-tested, practical approaches for dealing with disasters. These techniques help work through the processes of triage, isolate, diagnose, troubleshoot, repairs and improve hardware, software, and ultimately wetware.
Changing the sequence of a machine’s startup or workflow can make a big difference.
When interviewing people about breakdowns, learn how to find clarity and uncover hidden information in their statements.
The need to step away from a project–you can’t always force a solution.
Tracing a problem through a workflow. Bare Bones: paring it back to the bare essentials.
Making sure a repair is necessary
Listening to what a machine is saying.
If you can make the failure happen at will, you’ll also know when it’s fixed. Also, Black Boxes and intermittent problems.
The advantages of taking a machine back to a more primitive state.
The need for minimalism so that information can be derived from your actions.
Keep track of things as you make a repair.
Prerequisites for operation. The first question a troubleshooter might ask.
Seeking other perspectives to help you out of a rut.
When problems look the same, but they’re really not.
Managing when and where you troubleshoot.
A working model can be as good as a manual. Let’s Be Reasonable: logical principles and the law of simplicity.
When to call in a pro.
Starting points for the troubleshooting process.
Recent modifications or additions often point the way to the cause.
Getting your machines to play nicely together.
Paying attention to context. Pinpoint causes by noticing shared symptoms.
Use the half-splitting method to quickly pinpoint the cause.
How to organize a team during a crisis. Plus, the benefits of teamwork for everyday problem-solving, with lessons from the world of “pair programming.”
Pinpointing why a system is slow, and making it go faster.
Learning important things about machines through stress testing and seeing them “at their worst.”
Knowing how a machine is supposed to function allows you to plot a course between “broken” and “working.”
Things to consider when deciding whether to fix or replace a broken machine.
Problems with a popular rule of thumb used to make the repair or replace decision, along with my suggestion of a better way to resolve the dilemma.
How to interact with other troubleshooters. Unexpected upsides when dealing with Customer Service behaviors and mindset of a great troubleshooter.
Not getting sucked into other people’s false beliefs.
Using all your senses.
Become interested in the world around you.
The importance of being organized, systematic, detail-oriented, and logical.
Recognizing the difference between machines and the purposes they serve. The many paths you can take to a repair.
Keeping yourself externally focused is critical, especially at the beginning of a troubleshooting exercise.
Deliberately choosing your commitments, setting expectations. Is This Normal?: an ode to data collection.
Eliminate trouble before it arises.
A method to document and communicate your hard-won repair knowledge.
How to know when you’ve nailed it for good.
Using root cause analysis and the 5 Whys method to prevent failures from recurring.
Using the emotion of a disaster to make meaningful changes.
The checklist is a simple, yet powerful, way to guide the fix-it process. As a means to prevent trouble, it puts the best way of doing something in the hands of machine operators and designers.
The unfortunate reality of failures caused by fraud and sabotage.
How to interact with other troubleshooters. Unexpected upsides when dealing with Customer Service behaviors and mindset of a great troubleshooter
The final step is communicating what was learned.
Improperly tuned alerting systems will eventually be ignored.
Questioning a machine’s past performance.