In a Distance Debugging situation, especially one that involves a large physical distance, nothing is more valuable than a trusted contact. A trusted contact ideally is another member of your team that is working with you to solve problems, but more likely it is someone from your customer, either a user or local administrator, that will act as your eyes and fingers.

The qualities that you need in a trusted contact include (in approximate order of importance):

1. Attention to Detail - This can't be stressed enough. I would much prefer a totally naive user with no technical skill that will faithfully report error messages and follow directions perfectly than the opposite. Sometimes a highly technical contact will try to out-think you to the detriment of the debugging effort.
2. Enthusiasm/Passion - I am firm believer that we ultimately do not commit to things that we do not enjoy. A tepid contact who doesn't care about the fate of the system will not make the extra effort to make sure that you solve the tough problem.
3. A Thick Skin - This is needed for two reasons. First, when time is short and tempers flare, you need to know that your contact can take a little sarcasm. Second, you will need them to check and recheck something, and then check it again just for your peace of mind. They need to understand that you are being thorough, and not that you are questioning their competence.
4. Domain Knowledge - They should understand the world of the users of the system, in order to answer certain questions, although this is less important
5. Technical Knowledge - Some technical knowledge can be helpful, especially simple utility things like how to open the Windows Control Panel. However, this is the generally not very important.

The first thing to do when looking for a trusted contact is look for someone with these qualities. Often, I will look at a very detailed bug report and think, "This person looks like they would be a good contact to make." I will immediately try to get in touch to let them know that I appreciate their report and to gauge their interest in working with me on a regular basis. One of the easiest ways to determine this is by simply giving them a small task such as getting the answer to a question for you. For example, I might ask, "Can you check around with other users in your area and see if any of them use the X feature? We're trying to decide if we want to keep it around." If I check in with them the next week and they've polled 5 or 10 users, then I know I can count on them in the future. On their end, they usually realize that this gives them more of an opportunity to influence and guide future development, and it gives them buy-in.

Tomorrow: Developing a Trusted Contact, Part II