covered, regardless of whether or not we thought we could fix it. If we could fix it, we just cancelled the call. If we could not, we were already well on our way to getting the right person on the phone. Troubleshooting in a Team Environment When there is a team of people troubleshooting the same problem, someone needs to be the leader. I could write an entire book on this subject alone. If you find yourself troubleshooting as part of a team, work only on the piece of the puzzle you've been assigned. If you try to fix someone else's piece, you're wasting your time as well as his. If someone else is trying to solve a problem, standing over his shoulder and yelling out ideas will not help. If you're sure of the answer, but no one is listening, find a way to prove your solution, and push to be heard. The Janitor Principle The Janitor Principle states that explaining your problem to someone who doesn't understand it will cause you to make connections you've previously missed. This is an amazingly powerful tool. To explain a complex problem to someone who doesn't un- derstand it, you need to reduce the problem to its simplest elements. This action forces you to think about your problem from a different viewpoint. Looking at a problem differently is often all it takes to find a solution. Chapter 39: Failures CHAPTER 40 GAD's Maxims Over the years I've been in the industry, it has become apparent to me that there are certain driving forces in the IT universe. These forces are evident in just about all aspects of life, but their application is never more evident than it is in IT. In every situation where an engineer does not get to do what she wants to do-or worse, in her eyes, to do what she believes is right-these forces come into play. I believe that if more people understood them, there would be less conflict between engineers and their superiors. My initials are GAD, and people often call me by that acronym. It is with the utmost humility that I present to you GAD's Maxims. Maxim #1 The driving forces of network de