> > I wouldn't call it a "misconception", but I want to echo Paul's > comment. I would venture over 90% of the engineers I work with have no > idea how to troubleshoot properly. Thinking back to my own education, > I don't recall anyone in highschool or college attempting to teach > troubleshooting skills. Most classes teach you how to build things, > not deal with them when they are broken.
Look for people who grew up on a farm. They are used to figuring out how to fix things they haven't seen before and generally attempt to gain knowledge of the fundamental principles of how things work so they can apply those principles in a similar situation. For example, such a person may know enough about troubleshooting both gasoline and diesel engines and might have a better understanding of the underlying fundamentals of internal combustion engines to do a passable job troubleshooting something they have never seen before (air, fuel, timing). There is a certain APPROACH to troubleshooting that transcends various fields. Some naturally have a talent for it, others aren't so good at it. Such people might be better in a multi-vendor network when there is a problem. You can generally spot those people not by what they know, but by the quality of the questions they ask. They generally know what they want to accomplish or what they are looking for, but they might want to know how that is done with this particular vendor's command set or how this particular vendor processes traffic. Some are natural designers, some are natural troubleshooters, some are natural documenters/support staff and they LIKE doing it. It takes all of those skills. One important thing to keep in mind, too, is that by identifying the skills and natural talents of your line staff, you yourself are being a value multiplier to your organization. You are making best use of the resources that you have at your disposal and are improving the efficiency of the organization as an organic entity. So this benefits everyone in the entire organization, including you.
