click and follow directions
Troubleshooting Techniques: Introduction
December 19th, 2007When something breaks somebody needs to fix it and when they do gratitude is typically sent in that person’s direction. The very nature of engineering is to create new things. During this process, the creations are inevitably passed around to different people during design, prototyping, testing, and manufacturing phases. As products progress through these steps (or whatever sequence is used in your specific situation), it is rare that everything goes smoothly.
As such, something will break along the way, somebody will receive accolades for fixing them, and those kudos will appear on that persons performance evaluation. It might as well be you. Few things enhance a work reputation like being the person who fixes broken stuff. This series examines the essential attributes of successful troubleshooting as well as provides a common set of steps to increase the odds of finding a solution as quickly as possible.
- Introduction
- Wrath of Khan Anecdote
- Knowledge, Access, and Creativity
- Step 1 - Were all the instructions followed correctly?
- Step 2 - Is this happening here or is it happening everywhere?
- Step 3 - Something changed recently, what is it?
- Step 4 - What isn’t broken versus what is?
- Step 5 - It’s fixed, now what?
- Final Thoughts
Are you kidding me? Take a look at my picture. If I’m not a genuine, bona fide nerd I’m not sure who is. I'm currently employed as Portals and Marketing Solutions IT Chief Architect at Hewlett Packard and write here about career best practices for techies. Why? Because I wish I'd had this kind of free advice earlier in my own career and now I'm trying to "pay it forward". See more in 
August 21st, 2007 at 3:53 pm
Jed Daniels over at http://www.itsnotthenetwork.com has a nice extension to some of the ideas in this guide here:
http://www.itsnotthenetwork.com/how-to-troubleshoot/
His advice: DEFINE THE PROBLEM FIRST. That’s a great point. Unless everyone agrees on what it is you are trying to solve, you’re bound to have trouble when you think you’ve fixed it and others don’t share that opinion.
March 29th, 2008 at 12:13 pm
[…] Troubleshooting Techniques: Introduction (older) (newer) Happy Holidays! […]
March 29th, 2008 at 12:16 pm
[…] Introduction […]
March 29th, 2008 at 12:18 pm
[…] Introduction […]
March 29th, 2008 at 12:20 pm
[…] Introduction […]
March 29th, 2008 at 12:22 pm
[…] Introduction […]
March 29th, 2008 at 12:24 pm
[…] Introduction […]
March 29th, 2008 at 12:26 pm
[…] Introduction […]
March 29th, 2008 at 12:27 pm
[…] Introduction […]
April 1st, 2008 at 8:06 am
[…] Despite my lack of knowledge, I encouraged her to explain to me what the problem was. She knows as much about Java programming as I do about making curtains, but I’ve found over the years that by trying to explain a problem to somebody with no prior knowledge of the material, it forces you to think through your steps more precisely. Often, you discover your own mistake with a step you didn’t realize you missed because your expertise clouded your troubleshooting approach. […]
April 1st, 2008 at 6:01 pm
[…] my line of work that usually means meeting a deadline, troubleshooting some big problem that’s broken, or presenting a new and perhaps controversial idea to the people in charge. I came […]