Contributed by Bruce Stegner, Ph.D, Executive Consultant

I am new to this blog and to social networking via electrons. I have been to a fair number of SAS gatherings and have been reflecting on various aspects of them. I thought it might be a good idea to focus on people who have never been to a user group, forum or drinking bout.

My first SAS Users Group International (SUGI) was in San Francisco in the 1970s. My biostatistician/programmer friend and fellow classmate from the University of California San Francisco encouraged me to go. This leads me to the first consideration—“How do you get to go?”

I was just finishing graduate school and had the naïve belief that if something was morally good then it should happen. Even before going, I discovered that managers would get nervous about sending valuable staff away. They had fears that these types of events were one big party, that their staff would find new jobs and all they could see was RISK. So I quickly learned that getting the support to attend involved making a strong business case from the very beginning.

What makes a strong business case? “We’re having a very difficult time getting the &1 (that is shorthand for any name you wish) module to run efficiently. We’ve been struggling with this for three months to little avail. I notice from the agenda that people on the other side of the country are going to present on a very similar problem.” Another example, “When we built our strategic plan, we said we want to be a leader in the use of animated graphics to present specialized findings. If we go to this meeting we can meet with the SAS developers and ask them to develop tools for us to use. This would be much more cost efficient than developing them ourselves.” Believe it or not, there was a time when SAS did not have either power or bioequivalence tools available. Over the years I raised both topics at one time or another. In other words these interactions work.

Now that you have figured out how to get the support to attend, what is a good strategy for attending? To me one of the most underrated factors is getting there as early as possible. Register the night before if possible. Because at that time you will have more time to talk with friendly strangers than just about any other time during the conference. Once the kick-off starts everyone is schedule-driven and hard to connect with. Take advantage of the message boards (like those on sasCommunity.org or support.sas.com) to communicate with specific individuals or to find others who are interested in common topics.

Conflicts. Somewhere in the depths of the planning division is a gnome who reads my mind and plans two or more fascinating sessions at exactly the same time, making it impossible for me to attend both. The electronic media that is given out afterwards abates the problem somewhat, but it is hard to ask a question of a CD. If you are lucky, you are attending the meeting with colleagues and can split up the sessions, but it never fails that one of them wants to go look at all the new sans serif fonts and cares naught about performance issues or multivariate malarkey methods.

One thing to remind your co-attendees is that you will probably be asked to give presentations on what you did when you return to the mother ship. One strategy is to spend half of your time in each of the sessions. When I have tried that I have ended up with just about an empty hand. Swinging by and picking up the handout (if there is one) can be somewhat helpful. If you are going to be a session commuter please sit in the back to minimize interruptions. As someone who occasionally presents at meetings, it is very distracting to have someone get up and walk out in the middle of your talk.

The second consideration is that if you think your cell phone, g4device or teletype is going to go off in a session because you are indispensible please put it on recreational vibrate, sit in the back, and leave the room before you start your conversation even if it is in Braille. All of these things distract others. You may be the best informatics person since Turing, but that kind of stuff is just rude.

Final thoughts for today. Managers. I have managed a number of IT shops, usually focused around health sciences. We developed a few policies which helped us manage sending people to SAS sessions. First, we would only send people who were in at least their second year with us. Second, we sent them in style to acknowledge their great contributions. Third, we gave them assignments. “Hey Joe, while you are there, see if you can find someone who has worked with Medicare data that might be willing to be a consultant to us.” Fourth, every person who went was expected to report to the whole team on what they did, what was helpful, what wasn't, and their recommendations to others. The latter helped to include our newer employees and gave them something to look forward to. Attitudinally, don’t begrudge your employees these sessions. Instead budget for them and look at these sessions as a way to reduce turnover.

Bruce L. Stegner, Ph.D. is an executive consultant in the state of Washington and has worked as a scientific manager on both coasts of the USA. He teaches SAS programming and has written a 100-page book for beginners. Contact Bruce at brucestegner@comcast.net.