Navigating The Conference Call

Tips for Navigating a Technical Conference call

1. Be polite. When you join an existing conference call you will be the new person. Some people on the call may have been on it for hours and are exhausted, while others may be looking for reassurance from you. Some may even be looking to discredit you so it’s important that you don’t step on any toes. Make sure everyone knows that you are there to help.

2. Announce yourself. When you join, tell everyone who you are and what your role is. Be specific and try to speak with authority.

Depending on your particular conversation style and the nature of the call, this can be a good time to break the ice. Sometimes, asking a simple question like “How’s everyone doing?” can elicit an offhanded remark or joke which can be a good segway into gathering background information.

3. Get the Lay of the Land. Asking for background about the problem here is an effective way to start scoping the issue and discovering who the main players on the call are.

Write down names and what they do. I can’t stress this enough. It's polite and when you need something from that person it cuts down on confusion. Repeatedly having to ask for the Networking Guy’s name shows the whole call that you’re too lazy to remember.

Get as much background as you can. This is the best chance to scope the issue and have everyone on the call agree to it. If there is disagreement here between other people on the call it isn’t necessarily a bad thing. The more they talk and the more you hear the story from a different perspective the more information you have.

Find out who is leading the call. A large conference call needs to have someone running it. It may be you and if that’s the case you probably need to know.

4. Set the agenda. Once you have the scope of the issue make sure everyone on the calls knows what it is. When you are trying to solve a technical problem the people involved need to know that is purpose of the call and nothing else.

5. Pre-Troubleshooting cleanup.

Get rid of static or noise on the line. If somebody’s line is generating static or there are dogs barking the in background you can politely ask them to mute their phones. Let people on speaker phones know if you can’t hear them.

Often, the biggest deterrent in a technical conference call is having to give updates and explain the details of what you’re doing to non-technical people. In an ideal situation, there will be a TAM or other liaison who will give those updates to the people who need to know.

Keep in mind that all the members of the call have a reason for being there and may feel a need to understand the discussion. However, continually having to stop the troubleshooting process to update and explain the situation often does more harm than good. If phrased correctly and politely, it isn’t bad to ask the managers to exit the call or mute. The best case scenario is they let the tech people be tech people. The worst thing that can happen is that they say no.

 

 

Conference Call Mistakes

1.  The Mute Button. If you go on Mute, make sure it doesn’t blare music to the rest of the call.

2. Eating/Drinking. If you are going to eat or drink while on the call, ensure you are properly muted. Nobody wants to listen to somebody else eat a bag of Cheetos and swig a Mountain Dew.

3. Disappearing from the call. There are some pretty good reasons you need to drop off the call. Just make sure everyone knows you have left and give an estimation of when you will come back. When you return, announce that you’re back.

4. The Blame Game. You know it’s a vendor’s problem. The vendor knows it too but won’t admit it. Don’t get into a word fight. Find a way to get evidence.

On a similar note, try not to make anyone at the customer’s organization look bad. The vast majority of technical problems are caused by someone making a change to the infrastructure and not realizing or admitting it. Assigning blame is for the managers. Fixing the problem is for the engineers.

5. Veering off the road to resolution. Always remember the problem statement. If you find other issues that aren’t relevant to your problem don’t get distracted trying to track them down.